可能重复：
How to version REST URIs
我是REST-ful API设计的新手，我似乎无法就如何在REST-ful风格中实现API版本找到共识。我遇到的可能性包括：
基于网址（例如/myApi/version5/someCall）
这种方法对服务器和客户端都很有用......但它似乎并不是非常好的（网址应该与资源相对应，API版本确实不是资源的一部分）
基于有效负载（例如$.ajax({data:{version:5, ...）
这种方法具有很强的兼容性，但是：
A）服务器需要实际解析有效负载以确定版本（这往往会使版本检查逻辑“更深”，而不是应该的版本）
B）同样，从我所说的哲学来看，这不是非常好的（据我理解，我POST的数据应该只是我想要创建的资源的数据）
基于标题（例如Accept application/json;version=5）
这种方法被建议here，我发现它是如何制作REST-ful API的绝佳资源。然而，在这种特殊情况下，我一直在遇到问题，因为无论我做什么，我似乎无法让jQuery在标题中发送版本。
现在，我确信如果我尝试的话，我最终可以在方法＃3中解决jQuery问题，但它让我觉得我可能会在基于标题的版本控制中走错路;如果我遇到麻烦，我们API的消费者似乎也会这样做。
因此，在创建REST-ful API时，任何人都可以解释哪种版本化方法：
A）将与其他技术（浏览器，框架等）一起使用最佳技术
B）最忠实地实施“REST-ful”理念
C）是最常见的（这个并不重要，但它确实是前两个的指标）
换句话说，在REST-ful API中处理版本控制的最佳方法是什么？
答案 0 :(得分：2)
解决方案1似乎实用且简单。对于您的参考，twitter（api.twitter.com/2）和linkedin（api.linkedin.com/v1）使用基于网址的版本控制，Google数据（&v=1.0）使用基于Payload。我的实践经验是基于URL的版本控制。
如果您想进行分析，请查看此api directory
答案 1 :(得分：1)
我强烈建议解决方案1，它清晰简单 - 不仅仅是StackOverFlow使用它：https://api.stackexchange.com/2.1/questions?order=desc&sort=activity&site=stackoverflow：）