rest - 供应商 MIME 类型(用于 API 版本控制)

Question

我已经阅读了许多关于版本控制 RESTful 服务的 Stack Overflow(和其他)帖子。
老实说，这有点压倒性的。

我决定使用 Accept: header 用于我们的(边缘)RESTful 服务，以便客户端可以请求资源的特定版本。我不清楚的是在 Accept header 中指定什么。

我经常看到的例子是这样的:

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 header 或 Accept: */* 怎么办？

欢迎任何其他建议。当然，目标是允许更改服务为给定资源返回的内容，但不会破坏现有客户端。

这是我最近查看的资源的简短列表:

Best practices for API versioning?

How to version REST URIs

REST api versioning (only version the representation, not the resource itself)

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

Answer 1

因为我决定关注 jsonapi.org标准，我决定按照您的示例所示进行操作。

关于您的问题:

您的 MIME 类型应该注册

我认为每个版本和类型都应该注册，因为它们是唯一的类型

x-如评论

中所述，前缀已被弃用

application/json-v2将无效

您可以返回 415 Unsupported Media Type或者干脆 400 Bad Request