我已经阅读了许多关于版本控制 RESTful 服务的 Stack Overflow(和其他)帖子。老实说,这有点压倒性。
我决定为我们的(勉强)RESTful 服务使用 Accept: 标头,以便客户端可以请求特定版本的资源。我不清楚的是在 Accept 标头中指定什么。
我经常看到的例子是这样的:
Accept: application/vnd.mycompany.myapp.customer-v2+json
我的问题是:
我是否正确必须注册所有 vnd 类型?( http://www.iana.org/cgi-bin/mediatypes.pl )
版本和类型(即 -v2+json)是否是类型的一部分,因此每个版本和类型都需要注册?
是否有任何理由使用 vnd 而不是不需要注册的“x-”子类型?例如:
Accept: application/x-mycompany.myapp-v2+json
现有的 API 仅供内部使用,但将来会向客户公开。
不确定这是否有意义,但是否可以使用现有类型但添加版本?(当前 API 返回“application/json”)
Accept: application/json-v2
附加版本和类型的可接受格式是什么(例如 -v2+json)。
如果客户要求提供不受支持的版本怎么办?正确的响应是 406 吗?客户可以要求任何版本吗?或者更一般地说,如果客户端没有提供 Accept 标头或 Accept: */* 怎么办?
欢迎任何其他建议。当然,目标是允许更改服务为给定资源返回的内容,但不破坏现有客户端。
这是我最近查看的资源的简短列表:
- API 版本控制的最佳实践?
- 如何对 REST URI 进行版本控制
- REST api 版本控制(仅版本表示,而不是资源本身)
- http://www.lexicalscope.com/blog/2012/03/12/how-are-rest-apis-versioned/
- http://www.subbu.org/blog/2008/05/avoid-versioning-please
- http://www.informit.com/articles/article.aspx?p=1566460
- http://en.wikipedia.org/wiki/Internet_media_type#Prefix_vnd
- http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1