如何版本REST URI
版本REST URI的最佳方式是什么？ 目前我们在URI本身有一个版本＃，即。
http://example.com/users/v4/1234/ 对于此表示的版本4。
该版本是否属于queryString？ 即。
http://example.com/users/1234?version=4
还是以另一种方式完成版本控制？
我认为把它作为URI本身的一部分（选项1）是最好的，因为v4标识的是与v3不同的资源。 像第二个选项那样的查询参数可以用来传递与请求相关的附加（查询）信息，而不是资源 。
不要版本的url，因为…
- 你打破固定链接
- url的变化将通过您的界面像疾病一样蔓延。 你如何处理没有改变的表示，而是指向表示呢？ 如果您更改url，则会破坏旧客户端。 如果你离开的url，你的新客户可能无法正常工作。
- 版本控制媒体types是一个更灵活的解决scheme。
假设您的资源正在返回application / vnd.yourcompany.user + xml的一些变体，您只需创build对新应用程序/ vnd.yourcompany.userV2 + xml媒体types的支持，并通过内容协商的魔法v1和v2客户可以和平共处。
在一个RESTful接口中，对于一个契约来说，最接近的就是在客户端和服务器之间交换的媒体types的定义。
客户端用于与服务器进行交互的URL应由embedded先前检索的表示中的服务器提供。 客户端需要知道的唯一URL是接口的根URL。 如果您在客户端上构buildurl，那么向url添加版本号仅具有价值，而您并不想使用RESTful接口来创buildurl。
如果您需要对您的媒体types进行更改，将会破坏您的现有客户端，然后创build一个新的客户端，并让您的网站独立！
而对于那些目前的读者来说，如果我使用application / xml和application / json作为媒体types，这是没有意义的。 我们应该如何版本？ 你不是。 这些媒体types对于RESTful接口几乎没有用处，除非使用代码下载对它们进行parsing，在这一点上，版本控制是一个有争议的问题。
啊，我再次把我那古老的脾气暴躁的帽子。
从ReST的angular度来看，这根本就不重要。 不是香肠。
客户端收到一个它想要遵循的URI，并将其视为一个不透明的string。 把任何你想要的东西，客户端不知道这样的东西，它的版本标识符。
客户知道的是它可以处理媒体types，我会build议遵循Darrel的build议。 另外，我个人认为，如果需要在一个宁静的体系结构中更改4次使用的格式，应该会带来巨大的警告信号，表明您正在做出严重错误的事情，完全绕过devise媒体types以适应变化的需要。
但无论哪种方式，客户端只能处理一个可以理解的格式的文档，并按照其中的链接。 它应该知道链接关系（转换）。 那么URI中的内容是完全不相关的。
我个人会投票支持http：// localhost / 3f3405d5-5984-4683-bf26-aca186d21c04
一个完全有效的标识符，将阻止任何进一步的客户开发人员或接触系统的人质疑，如果应该把v4放在URI的开始或结尾（我build议，从服务器的angular度来看，你不应该有4版本，但4种媒体types）。
你不应该把版本放在URL中，你应该把版本放在请求的Accept Header中 – 看看我在这个主题上的post：
API版本的最佳实践？
如果你开始在URL中粘贴版本，你最终会得到这样的愚蠢的URL： http : //company.com/api/v3.0/customer/123/v2.0/orders/4321/
还有一些其他的问题也一样 – 看我的博客： http : //thereisnorightway.blogspot.com/2011/02/versioning-and-types-in-resthttp-api.html
有关REST API版本的这些（不太具体的）SO问题可能会有所帮助：
- 版本化RESTful服务？
- Web服务REST API版本控制的最佳实践
我想创build版本化的API，我发现这篇文章非常有用：
http://blog.steveklabnik.com/posts/2011-07-03-nobody-understands-rest-or-http
有一小部分关于“我希望我的API版本化”。 我发现它简单易懂。 症结在于使用头中的“接受”字段来传递版本信息。
我会在URI的末尾包含版本作为可选值。 这可能是一个像/ V4这样的后缀，或者像你所描述的查询参数。 您甚至可以将/ V4redirect到查询参数，以支持这两种变体。
如果REST服务在使用之前需要身份validation，则可以轻松地将API密钥/令牌与API版本关联，并在内部执行路由。 要使用新版本的API，可能需要一个新的API密钥，链接到该版本。
不幸的是，这个解决scheme只适用于基于authentication的API。 但是，它确实保留了URI之外的版本。
如果您使用URI进行版本控制，那么版本号应该位于API根的URI中，因此每个资源标识符都可以包含它。
从技术上讲，REST API不会因URL更改而中断（统一接口约束的结果）。 只有当相关的语义（例如API特定的RDF词汇）以非向后兼容的方式（罕见）改变时才会中断。 目前，很多人不会使用链接导航（HATEOAS约束）和vocabs来注释他们的REST响应（自描述消息约束），这就是为什么他们的客户端破坏。
自定义MIMEtypes和MIMEtypes版本控制不起作用，因为将相关元数据和表示结构放入短string中不起作用。 OFC。 元数据和结构会经常变化，所以版本号太…
所以要回答你的问题，最好的方法来注释你的请求和响应与词（ Hydra ， 链接的数据 ），并忘记版本或只使用非向后兼容vocab变化（例如，如果你想用另一个replacevocab）。
我投票支持MIMEtypes而不是URL。 但是原因与其他人不一样。
我认为这个URL应该是唯一的（除了那些redirect）来定位唯一的资源。 那么，如果你接受URL中的/v2.0 ，为什么它不是/ver2.0或/v2/或/v2.0.0 ？ 甚至是-alpha和-beta ？ （那么它完全变成了semver的概念）
所以，mimetypes的版本比URL更可接受。
