现实世界开发人员的问题：API 版本控制

后端世界令人着迷，充满了新事物等待您去探索。
一开始，您可能会被各种信息淹没，因此最好的理解方式是使用应用这些概念的常见示例。

在设计后端时，务必考虑一些因素。要考虑到未来的合约可能会发生变化，因此需要保持向后兼容性。

你的 API 可能会不断演变，你需要支持它们提供的功能。当它威胁到现有的客户端集成时，管理这种影响可能是一个相当大的挑战。

REST 没有指定任何版本控制方法，但更常见的方法是：

• 指定将其放在 URI 上的版本：
  https://api.example.com/v1/

• 使用自定义请求标头：
  Accept-version: v1

• 或者，添加到 HTTP Accept 标头
  Accept: application/json; version=1

使用这些方法，您的挑战在于管理包含多个资源版本的整个代码库。内容协商或许可以让您避免修改整个 URL 集合，但您仍然需要处理提供不同版本内容的复杂性。

另一种方法是开发一个消费者驱动的契约，允许消费者在请求中声明他们想要消费的数据。在最后一种情况下，你将责任委托给了客户端。

无论您采取什么方法，都需要对不断发展的合同进行一致且积极的治理。

请在此评论您推荐的或知道可以推荐给我们的其他方法。