[关闭]
@lsmn 2016-07-20T22:06:34.000000Z 字数 1576 阅读 3371

切勿版本化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

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注