切勿版本化 Web API

在最近的一次演讲中， 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