切勿版本化 Web API

阅读数:4614 2016 年 7 月 21 日

话题:REST语言 & 开发架构

在最近的一次演讲中,Sebastien Lambla指出,通过在 URI 中增加版本或者使用带有版本的媒体类型将 Web API 版本化在开放网络上是行不通的。我们真正需要的是,协定随着我们需要的变化而演化。此外,他还描述了避免版本化需求的方法。

Lambla 是一名 REST 架构风格顾问和倡导者。在他看来,版本化 Web API 的一个常见的原因是,避免我们使用的协定破坏客户端。我们希望客户端和服务器可以独立地修改,并且能够将 API 变化传达给客户端开发人员。Lambla 认为,从根本上讲,版本化是一种管理耦合的方法,本质上是一种变更控制。

一种版本化方法是在 URI 中增加版本,像这样:http://api.equestrian.magic/v1/。这样做的问题是,当 URI 指向一个资源(比如客户),其变化会导致使用旧的 URI 无法找到资源,除非我们使用重定向。Lambla 强调,资源 URI 永远都不应该变化,但如果使用一个新版本,它就有两个不同的 URI 了,这通常表示两种不同的东西,它们之间无法相互关联。

另一种方法是在域名中增加版本:http://v1.api.equestrian.magic/。这样,在实际创建一个新系统时,URI 就会变得难以理解。有多个系统和模型,但都是指向相同的数据模型,这会增加维护的困难。

第三种方法是使用带有版本的媒体类型。Lambla 认为,这种方法如今在 Web 上已经比较少见,但在企业中还相当常见。它以内容协商为基础,在 Accept 和 Content-Type 头信息的媒体类型中增加一个版本号:application/vnd.equestrian.ponies.v1+xml。Lambla 指出,不同的版本实际上还是不同的资源,在同一个 URI 上使用不同的媒体类型会破坏资源标识符。他援引Roy Fielding的话来说明他的观点:

当格式之间的不同实际上只是细节上的差别时,我们鼓励资源所有者仅仅使用真正的内容协商(不使用重定向)

在 Lambla 看来,在开放网络上,这些版本化技术没有一种可行。我们真正需要的是可以演化的东西,使用可以随着我们需要的变化而平滑演化的协定。在 Lambla 看来,这是一个很好理解的问题,而且与 Web 相关;数以百万计的微服务已经运行 25 年,也没有出现太多的问题,除了 HTTP 之外,也没有版本化。

可演化协定的第一个基础是向后兼容。Lambla 举了 HTML 的例子。HTML 有许多停用的元素,但它们仍然为客户端所支持,因为我们无法升级世界上所有的站点。同样的原则也应该运用在 API 上,因为它在演化的过程中仍然必须支持旧格式。

第二个基础是向前兼容。为了做到这一点,你必须忽略未知或者没有理解的东西。Lambla 举了CSS的例子。在 CSS 中,新属性会得到处理,没有任何问题。为了做到这一点,未知属性会使用回退原则来处理,这是一种获得扩展点的重要方式。

XML 仍然很常用,而且经常和 XML 模式一起使用。这时,为了支持演化,我们必须保证内容的灵活性。因此,Lambla 强烈建议不要在服务器以及客户端上验证模式。相反,我们应该只是找出我们需要的元素和属性,而忽略其他部分。

为了避免版本化,我们需要继续支持所有的特性,但我们不能将所有的变化永远都保留在 API 中。应该删除很少使用的旧特性。为了知道什么时候可以删除,我们需要使用指标度量使用情况。然后,我们就可以确定,比如,当使用率降到 1% 以下时,删除特性。

查看英文原文:Don’t Version Your Web API