如何版本REST URI
版本REST URI的最佳方式是什么？ 目前我们在URI本身有一个版本＃，即。
http://example.com/users/v4/1234/
对于此表示的版本4。
该版本是否属于queryString？ 即。
http://example.com/users/1234?version=4
还是以另一种方式最好地完成版本控制？
我会说把它作为URI本身的一部分（选项1）是最好的，因为v4标识的是与v3不同的资源。 像第二个选项那样的查询参数可以用来传递与请求有关的附加（查询）信息，而不是资源。
不要版本的网址，因为...
假设你的资源正在返回application / vnd.yourcompany.user + xml的一些变体，你需要做的就是创建对新应用程序/ vnd.yourcompany.userV2 + xml媒体类型的支持，并通过内容协商的魔法v1和v2客户可以和平共处。
在RESTful接口中，对合同最接近的是定义在客户端和服务器之间交换的媒体类型。
客户端用于与服务器进行交互的URL应由嵌入先前检索的表示中的服务器提供。 客户端需要知道的唯一URL是接口的根URL。 如果您在客户端上构建网址，那么向urls添加版本号仅具有价值，您无法使用RESTful接口进行构建。
如果您需要对您的媒体类型进行更改，将会破坏您的现有客户端，然后创建一个新的客户端并让您的网站独立！
对于那些目前认为如果我使用application / xml和application / json作为媒体类型的读者没有任何意义的读者。 我们应该如何版本？ 你不是。 这些媒体类型对于RESTful接口几乎没有用处，除非使用代码下载对它们进行解析，此时版本控制是一个有争议的问题。
啊，我再次戴上我那古老的脾气暴躁的帽子。
从ReST的角度来看，它根本就没有关系。 不是香肠。
客户端收到一个它想要遵循的URI，并将其视为一个不透明的字符串。 把任何你想要的东西放在里面，客户不知道这个东西就是它的版本标识符。
客户知道的是它可以处理媒体类型，我会建议遵循Darrel的建议。 另外，我个人认为，如果需要更改4次安静架构中使用的格式，应该会带来巨大的大量警告信号，表明您正在做出严重错误的事情，并完全绕过设计媒体类型以改变响应的需要。
但无论哪种方式，客户端只能使用它能够理解的格式处理文档，并按照其中的链接进行处理。 它应该知道链接关系（转换）。 那么URI中的内容是完全不相关的。
我个人会投票支持http：// localhost / 3f3405d5-5984-4683-bf26-aca186d21c04
一个完全有效的标识符，可以防止任何进一步的客户开发人员或接触系统的人质疑是否应该将v4放在URI的开始或结尾处（并且我建议，从服务器的角度来看，您不应该有4版本，但4种媒体类型）。
链接地址: http://www.djcxy.com/p/21973.html下一篇: What is the correct way to authorize and structure a RESTful backend