最近，有人要求我为API（或者Web服务）版本管理成本建立一种估算方法。我想分享这一估算，因为我觉得许多人还不清楚API/服务版本管理对成本的影响。

据JJ说，他们在工作过程中发现，创建API的成本取决于随后使用的版本管理方法：

[开发人员需要]了解的一个关键点是，即使服务消费者的成本在他看来很小，它也不只是单纯的成本问题，它是风险，它扰乱项目计划，并使预算不可用……由于变更常常不能为现有消费者带来直接的商业价值，所以他们不希望API有任何变更。

文章接下来将API版本管理方法分成三个不同的类别（读者可以查看全文来了解针对每一个类别的更深入讨论，包括JJ如何定义成本测量方法）：

“结（The Knot）”：“所有API消费者都连接到API的同一个版本，当API变化时，所有消费者都需要跟着变，实际上，这产生了一个横跨整个消费者集合/生态系统的巨大连锁反应。” 

点对点：“服务的每个版本都留在生产环境中运行，当需要某个版本时，消费者需要自己进行迁移。运维成本会随着生产环境中版本数量的增加而增加。” 

兼容性版本管理：“所有客户端都与API/服务的同一兼容性版本进行对话。” 

有了这些定义和使用JJ所描述的公式计算出的相关成本，就可绘制相对成本图，如下所示（y轴是成本，x轴是版本数量）： 

正如JJ所言：

[……]当API发生变化时，单一版本会迫使每个消费者都进行升级，对于生态系统而言，这是一种成本最高的方法。第二种方法需要维护版本的多样性，这样会好一些，但如果开发人员试图保持每个版本的升级或者交替运行旧版本，那么成本还是相当高。兼容性版本管理策略似乎最高效。

那么，其他人有什么想法？这一API版本管理成本计算方法在JJ和其团队研发该方法的环境之外是否适用？结合读者的个人经验，相对成本的解释是否合理？还有其它JJ和其团队没有涉及到的类别吗？