我看过Best practices for API versioning?,但不太相信答案,所以我用一个更具体的例子再次质疑版本控制部分。我有两个URI (一个将版本控制作为URI的一部分,另一个没有):
http://xxxx/v1/user/123 -> favored solution in discussed thread
http://xxxx/user/123
我怀疑第一个链接是否表达了REST的思想。我发现http://xxxx/v1/user/123
令人困惑,因为它暗示有一天会有像http://xxxx/v2/user/123
这样的更高版本的api。但这在REST术语中没有意义,api版本本身是HTTP 1.0或1.1,它已经在HTTP请求中发送。这种以REST资源为中心的视图与其他api接口有很大的不同,比如SOAP或Java接口(在这些接口中,通常在限定名中包含api版本)。
在静止状态下,版本控制唯一有意义的是资源的表示(例如,添加或删除新字段)。此版本控制属于内容协商的一部分,如:
http://xxx/user/123 + HTTP 'Accept' Header -> Content negotation through header
http://xxx/user/123?v=1 -> for perma-links/hyperlinks
有人可能会争辩说,这样的版本内容协商可能是路径中URI的一部分,但我发现这是违反直觉的,因为您可能会为相同的资源使用不同的URI,并且在某些时候必须维护重定向。
总而言之:在REST URI中没有api版本控制,只有资源表示的版本控制。表示version-info属于内容协商(如queryParam或HTTP 'Accept')。
你认为如何?在哪些事情上你会不同意/同意?
https://stackoverflow.com/questions/2024600
复制相似问题