业务需求在改变，这通常意味着API必须随之而改变。本文探讨当API必须改变时避免悲剧的五大关键策略。

API版本化和迁移是不得不解决的问题，特别是在应用程序接口和不断变化的业务优先级绑定越来越紧密的当下。但是，如果采取一些关键步骤，改动API就不会造成悲剧。

我们采访了Inversoft的CEO，Brian Ponterelli，他分享了五个他所使用的最重要的策略，能够减少API改动的风险。

1.文档化时间线

当API开发完成时，很可能已经计划的一些patch或者功能版本可能会破坏兼容性。要想避免你的API客户因此而愤怒，Ponterelli建议开发人员共享一份“事件日历”，记录下可能会影响到用户的任何变化。

“我们将这样的文档和发布摘要和文档放在一起，受到了用户的好评。”Ponterelli说。“有很多种方法，但是只要某个地方有“文档”，你就可以安心。”

2.拥抱语义版本控制

语义版本控制是业界针对patch版本的事实命名惯例，并且根据Ponterelli所说，使用它对于确保API版本控制不出乱子至关重要。这种正式的标准，已经被很多大公司采用 — Oracle，Google — 为版本号以及哪些兼容性会被破坏或者不受影响等，提供了清晰的说明书。

对于理解语义版本控制的API客户而言，Ponterelli说，很多客户确实理解，持续跟踪改动会很容易。对于不熟悉该领域的客户，也很容易找到介绍其如何工作的文档。

3.制定迁移策略以及向后兼容适配器

当新版本即将发布时，通常迫使开发人员打破某种兼容性。不幸的是，你的API使用者可能严重依赖于这些特定的兼容性，Ponterelli提醒到，当用户升级并且发现功能被破坏时，这可不太好。

Ponterelli建议解决这样问题的最佳办法是和使用你API的用户一起创建出清晰定义的迁移策略。这包括决定对于使用者的功能而言哪些兼容性必不可少，比如绝对不能失败的某个特定的功能或服务。如果无法确定完整的迁移策略，Ponterelli建议开发人员至少创建出向后兼容适配器，来帮助恢复必要的功能。

Ponterelli还建议开发人员和他们最大并且变化缓慢的客户一起开始API版本化之路，因为小型的，更为敏捷的公司通常更能接受API的变化。这给了你更多的时间来处理任何可能的问题，并且创建出需要的兼容性适配器。

4.抽象层次有所助益

除了创建可管理的兼容性，Ponterelli还建议开发人员添加反映API版本化频率的抽象层。他说Amazon创建的API，被抽象成经常变更的“细粒度”API和通常不变的“粗粒度”API。

通过这样抽象化API，你就可以帮助使用者清晰理解他们使用的API可能多久会发生变化，并且做好相应的计划。

5.考虑混合云方案

Ponterelli还指出当通过云预配API时，实现混合方案能够帮助用户抵御破坏。通过在本地保留一定数量的核心资源及其依赖，那么无论依赖的API如何变化，API用户都能够持续提供他们自己的版本。否则，他们可能会在API版本化发生的任意时间被强制要求升级，就不得不承担兼容性被破坏的风险。