4
如何管理版本化API的基础代码库？
我一直在阅读有关ReST API的版本控制策略，其中似乎没有一个要解决的问题是如何管理基础代码库。 假设我们正在对API进行一系列重大更改-例如，更改我们的Customer资源，以使其返回单独的forename和surname字段，而不是单个name字段。（对于此示例，我将使用URL版本控制解决方案，因为它很容易理解所涉及的概念，但是该问题同样适用于内容协商或自定义HTTP标头） 现在http://api.mycompany.com/v1/customers/{id}，我们在拥有一个端点，在拥有另一个不兼容的端点http://api.mycompany.com/v2/customers/{id}。我们仍在向v1 API发布错误修正和安全更新，但是新功能开发现在都集中在v2上。我们如何编写，测试和部署更改到我们的API服务器？我可以看到至少两个解决方案： 对v1代码库使用源代码控制分支/标记。v1和v2是独立开发和部署的，同时有必要使用修订控制合并来将相同的错误修正应用于两个版本-类似于在开发主要的新版本时仍支持先前版本时如何管理本机应用程序的代码库。 使代码库本身了解API版本，因此最终得到一个包含v1客户表示形式和v2客户表示形式的代码库。将版本控制视为解决方案体系结构的一部分，而不是部署问题-可能使用名称空间和路由的某种组合来确保请求由正确的版本处理。 分支模型的明显优势是删除旧的API版本很简单-只是停止部署适当的分支/标签-但是如果您运行的是多个版本，则最终可能会遇到复杂的分支结构和部署管道。“统一代码库”模型避免了此问题，但是（我认为吗？）将使得在不再需要不再使用的资源和端点时，很难从代码库中删除它们。我知道这可能是主观的，因为不可能有一个简单的正确答案，但我很好奇要了解维护多个版本的复杂API的组织如何解决此问题。