如果你想在API技术专家之间展开一场辩论，只要让他们分享他们对 "API版本 "的看法。可以肯定的是，你会在短时间内发现一些强烈的感受。术语 "API版本 "已经成为 "改变API "的同义词，这是理清支持已发布的API持续变化而又不给API消费者带来不必要问题的明智策略的第一个障碍。
大多数API不需要版本，它们需要的是支持随着时间的推移进行兼容变化的能力（这个词不那么华丽，对吧？）有很多技术支持兼容变化的例子，比如TCP/IP、HTTP和HTML。大多数编程语言也是这样做的。成功地实施兼容的变化需要做出支持变化的承诺，并长期坚持这一承诺。就这么简单，但并不那么容易。
最有效的兼容变化的API可以继续增加功能而不破坏现有的API消费者--即使是多年前创建的消费者。最不有效的API变化要求所有的API生产者和消费者在每次API设计更新时都要重写和重新发布他们的代码。成功的关键是，从一开始就设计好对兼容变化的支持。有了这个支柱，随着时间的推移，实施和发布兼容版API的过程会变得更加一致、可预测和有弹性。
而这正是我们都需要的，对吗？
版本划分是对客户的 "中指"。
在网络上维护API的关键挑战之一是处理随时间变化的问题。简单地说，一旦你发布了你的API，人们开始使用它，这个接口就代表了一种依赖性。API的消费者依赖于API的稳定性和可靠性。
但是很多时候，服务器端的团队（API生产者）忽略了这种依赖性。相反，他们只是简单地做出改变，而很少考虑到他们传递给API消费者的努力成本。正如Roy Fielding（REST名人）在2013年的一条推文中所说：
"......'v1'是对你的API客户的一个中指......"
从API生产商到API消费者的中指，本质上意味着，"是的，我们改变了我们的API，处理它"。 好消息是，通常的做法是在一个新的URL上开始一个新的版本--从api.example.org/v1/customers移到api.example.org/v2/customers。至少这样可以将变化隔离到一些新的分支。但是，情况变得更糟了；这些割裂