基本上,我认为对 REST api 进行版本控制是个好主意。这是常识。通常您会遇到两种执行此操作的方法:
- 或者,您的 url 中有一个版本标识符,例如
/api/v1/foo/bar
,
- 或者,您使用标头,例如
Accept: vnd.myco+v1
.
到目前为止,一切都很好。这是什么几乎所有大公司都这样做 http://www.lexicalscope.com/blog/2012/03/12/how-are-rest-apis-versioned/。两种方法都有其优点和缺点,并且讨论了很多此类内容here https://stackoverflow.com/questions/389169/best-practices-for-api-versioning.
现在我在 Twilio 看到了一种完全不同的方法,如上所述here https://blog.apigee.com/detail/restful_api_design_tips_for_versioning。他们使用日期:
在编译时,开发人员会包含编译代码时应用程序的时间戳。该时间戳出现在所有 HTTP 请求中。
当请求进入 Twilio 时,他们会进行查找。根据时间戳,他们可以识别创建此代码时有效的 API,并进行相应的路由。
这是一个非常聪明和有趣的方法,尽管我认为它有点复杂。例如,很难理解时间戳是编译时间还是 API 发布时的时间戳。
现在,虽然我不知何故发现这也很聪明,但我想知道这种方法的真正好处是什么。当然,这意味着您只需记录 API 的一个版本(当前版本),但另一方面,它使得跟踪已更改的内容变得更加困难。
有谁知道这种方法的优点是什么,那么为什么 Twilio 决定这样做呢?
请注意,我知道这个问题听起来好像答案主要基于意见,但我猜 Twilio 这样做有充分的技术理由。因此,请不要以主要基于意见的方式关闭这个问题,因为我希望答案不是这样。
有趣的问题,+1,但据我所知,他们只有两个版本:2008-08-01
and 2010-04-01
。所以从我的角度来看,这只是另一种拼写方式v1
and v2
所以我不认为有技术原因,只是偏好。
这是我在他们的决定中所能找到的全部:https://news.ycombinator.com/item?id=2857407 https://news.ycombinator.com/item?id=2857407
EDIT:请务必阅读下面的评论,其中 @kelnos 和 @andes 提到使用这种方法来版本 API 的优点。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)