相关疑难解决方法(0)

Web服务REST API版本控制是否有任何已知的方法或最佳实践？

我注意到AWS通过端点的URL进行版本控制.这是唯一的方法还是有其他方法来实现同一目标？如果有多种方式,每种方式的优点是什么？

我看了一下API版本的最佳实践？,但我不太相信答案,所以我再次用更具体的例子质疑版本控制部分.我有两个URI(一个版本作为URI的一部分,一个没有):

http://xxxx/v1/user/123    -> favored solution in discussed thread
http://xxxx/user/123             

我怀疑第一个链接是否表达了REST的想法.我觉得很http://xxxx/v1/user/123困惑,因为它表明有一天会有更高的api版本http://xxxx/v2/user/123.但这在REST术语中没有意义,api版本本身是HTTP 1.0或1.1,它已经在HTTP请求中发送.这个以REST资源为中心的视图与其他api接口(如SOAP或Java接口)非常不同(其中通常有限定名称的api版本).

在REST中,版本控制唯一有意义的是该资源的表示(例如,添加或删除新字段).此版本控制属于内容协商的部分,如:

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版本,只有资源表示的版本控制.表示版本信息属于内容协商(作为queryParam或HTTP'接受').

你怎么看？你不同意/同意哪些事情？

我得到了改变链接uris的好处,但这不是这个问题的关键所在.

我的意思是可移动性是为服务添加新功能或修改(如果可能)现有服务,实际上就是这样.

SOAP并不是那么糟糕,因为REST社区倾向于在可演化性方面谈论它.例如:

1. 在REST中我们可以添加新的rel-in SOAP,我们可以添加新方法.两种类型的旧客户端都将继续使用新服务.
2. 在REST中,我们可以添加新的表单字段并设置其默认值 - 在SOAP中,我们可以将服务参数作为一些ServiceArgs类,并向ServiceArgs添加一个新字段.这很难看,但确实有效.

什么是SOAP客户端中断的可演化性示例,而您无法对其执行任何操作,而REST客户端正在优雅地处理这种情况？

谢谢!