像 Twilio 一样按日期对 REST api 进行版本控制有什么好处？

基本上，我认为对 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 的优点。