切勿版本化Web API

微服务 Web API 版本化

摘要

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

正文

在最近的一次演讲中，Sebastien Lambla指出，通过在UR中增加版本或者使用带有版本的媒体类型将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