相关疑难解决方法(0)

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

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

我一直在寻找如何使用Spring 3.2.x管理REST API版本,但我找不到任何易于维护的东西.我先解释一下我遇到的问题,然后解决一个问题...但我想知道我是否在这里重新发明了这个问题.

我想基于Accept标头管理版本,例如,如果请求具有Accept标头application/vnd.company.app-1.1+json,我希望spring MVC将此转发给处理此版本的方法.并且由于并非API中的所有方法都在同一版本中发生更改,因此我不希望转到每个控制器并更改任何版本之间未更改的处理程序.我也不想有逻辑来确定控制器本身使用哪个版本(使用服务定位器),因为Spring已经发现了要调用的方法.

因此,采用版本1.0到1.8的API,其中版本1.0中引入了处理程序并在v1.7中进行了修改,我希望以下列方式处理它.想象一下,代码在控制器内部,并且有一些代码能够从头部中提取版本.(以下在Spring中无效)

@RequestMapping(...)
@VersionRange(1.0,1.6)
@ResponseBody
public Object method1() {
   // so something
   return object;
}

@RequestMapping(...) //same Request mapping annotation
@VersionRange(1.7)
@ResponseBody
public Object method2() {
   // so something
   return object;
}

这在春天是不可能的,因为2个方法具有相同的RequestMapping注释并且Spring无法加载.这个想法是VersionRange注释可以定义一个开放或封闭的版本范围.第一种方法从版本1.0到1.6有效,而第二种方法从版本1.7开始(包括最新版本1.8).我知道如果有人决定通过99.99版本,这种方法会中断,但这是我可以忍受的.

现在,由于上面的内容是不可能的,如果没有对Spring的工作方式进行认真的修改,我就会考虑修改处理程序与请求匹配的方式,特别是编写我自己的方式ProducesRequestCondition,并在那里有版本范围.例如

码:

@RequestMapping(..., produces = "application/vnd.company.app-[1.0-1.6]+json)
@ResponseBody
public Object method1() {
   // so something
   return object;
}

@RequestMapping(..., produces = "application/vnd.company.app-[1.7-]+json)
@ResponseBody
public Object method2() {
   // so something
   return object;
}

通过这种方式,我可以在注释的产生部分中定义关闭或打开的版本范围.我工作的这个解决方案现在,随着我仍然不得不更换一些核心Spring MVC类(的问题RequestMappingInfoHandlerMapping …

版本REST URI的最佳方法是什么？目前我们在URI本身有一个版本#,即.

http://example.com/users/v4/1234/

对于此表示的第4版.

该版本是否属于queryString？即.

http://example.com/users/1234?version=4

或者版本控制最好的另一种方式？

在阅读了很多关于REST版本的材料之后,我正在考虑对调用进行版本控制而不是API.例如:

http://api.mydomain.com/callfoo/v2.0/param1/param2/param3
http://api.mydomain.com/verifyfoo/v1.0/param1/param2

而不是第一次拥有

http://api.mydomain.com/v1.0/callfoo/param1/param2
http://api.mydomain.com/v1.0/verifyfoo/param1/param2

然后去

http://api.mydomain.com/v2.0/callfoo/param1/param2/param3
http://api.mydomain.com/v2.0/verifyfoo/param1/param2

我看到的优点是:

• 当呼叫改变时,我不必重写我的整个客户端 - 只有受改变的呼叫影响的部分.
• 那些工作良好的客户端部分可以继续保持原样(我们投入了大量的测试时间来确保客户端和服务器端都稳定.)
• 对于已更改的呼叫,我可以使用永久或非永久重定向.
• 向后兼容性将是轻而易举的,因为我可以保留较旧的呼叫版本.

我错过了什么吗？请指教.

我已经阅读了许多关于版本化RESTful服务的Stack Overflow(和其他)帖子.说实话,这有点压倒性的.

我决定对我们的(边缘)RESTful服务使用Accept:标头,以便客户端可以请求特定版本的资源.我不清楚的是在Accept标头中指定的内容.

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

Accept: application/vnd.mycompany.myapp.customer-v2+json

我的问题是:

1. 我是否正确所有vnd类型必须注册？(http://www.iana.org/cgi-bin/mediatypes.pl)

2. 版本和类型(即-v2 + json)是该类型的一部分,因此需要注册每个版本和类型吗？

3. 是否有任何理由使用vnd而不是不需要注册的"x-"子类型？例如:

   Accept: application/x-mycompany.myapp-v2+json
   

   Run Code Online (Sandbox Code Playgroud)

   现有的API仅供内部使用,但将来会向客户展示.

4. 不确定这是否有意义,但可以使用现有类型但添加版本吗？(当前API返回"application/json")

   Accept: application/json-v2
   

   Run Code Online (Sandbox Code Playgroud)

5. 附加版本和类型的可接受格式是什么(例如-v2 + json).

6. 如果客户端要求提供不受支持的版本,该怎么办？406是正确答案吗？客户可以请求任何版本吗？或者更一般地说,如果客户端不提供Accept标头或Accept:*/*,该怎么办？

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

这是我最近查看过的一小部分资源:

• API版本控制的最佳实践？
• 如何版本REST URI
• REST api版本控制(仅表示表示,而不是资源本身)
• 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