第一次尝试，很少能够定下来API的最终版本，因为，API最终版本被视为非常重要、且几乎是不可避免的一项任务。

随着时间的推移，服务接口肯定会发生变化。尽管经历过大量努力和探索后，VPI 1.0版本也很难创建出完美的接口。幸运的是，处理不可避免的API版本化决策问题并不是十分困难的事情。

API版本化并非流程问题，而是技术问题。从技术的角度来看，版本化是非常简单的一件事情。需要判断的是，这些更改是否会影响向后兼容接口。当API版本更新时，向后兼容接口同样也可以正常传输信息，而从API反馈的信息应该仍然可以再发送回去。考虑到，API用户反馈信息的行为不可控，因此，我们应该考虑使用上述功能。

一般来说，如下根请求变更是考虑过后端兼容性的：

• 设置一个终端（例如，新型REST资源）
• 针对于现有终端设置操作（如，当使用SOAP时）
• 在请求接口处设置选项栏

在现有请求接口处将必填选项改为可以选择的类型

• （无论是否可选）为反馈模块设置选项栏
• 特别指出，如下请求变更是没有考虑后端兼容性的：
• 在请求接口处设置必填选项
• 在必填请求处设置预选栏
• 去除请求或者反馈选项处的必填限制（改为可选操作）
• 将此前需求反馈栏设置为可选性质
• 改变请求或者反馈模块中两个选项栏之间的结构或者关系

如果一种接口可以具备后端兼容性，那么最好在恰当的位置要做一些改动。现有使用者应该继续保持以前的工作状态，如果没有必要，那么我们为什么又要进行更改呢？如果他们也不需要，我们又为什么为创建版本而付出努力呢？

如果新街口不具备后端兼容性，我们就应该放弃使用。最容易的方法是创建一种新后端，例如在 URL处设置一种版本标识。但是，如果通过请求我们可以明确的分辨出应用哪种版本的话，那么我们就可以继续使用现有后端。例如，只有当信息与版本号相连接后，我们才可以使用定制的HTTP报头，然后，你才可以根据具体的实施情况追溯相应的请求。

此时API管理系统或者网络基础设置才发挥了重要作用。网关对于大多数（如果不是全部的话）API管理平台来说是非常常见的特征。在确定API实施选择哪种版本和路由时应该设置一处网关。然而，我们要迎接的一项共同的挑战是，版本1.0也许还未具备旧版本的路由器，因此，现在我们要在多需求的情况下查找到路由器的插入点。在大多数情况下，无需更改用户末端可见性就可以实现该目标，但是，考虑到API本身的设计架构，这将会是一次复杂的变更。

API版本化中使用转移技术

只有彻底摆脱以前的操作方式时，转换技术才能发挥作用。如果你还是继续运行以前的实现方式时，那么我们可以简单地路由到正确地请求。然而，一旦不能使用以前的实现方式，那么唯一可行的机会就是拒绝请求或者将请求转移到最新的版本中进行后续处理。

迁移技术只能解决一小部分问题。即使通过转移技术我们也不能设置必填选项。然而，当必要信息没有以恰当的结构或者形式出现时，我们还是可以通过转移技术来解决这种问题。我们需要决定的是，是否还要继续使用以前的实践方式。

API现有用户非常愿意继续使用以前的实现方式，除非，需要一种新功能或者信息，否则这些用户是不会关注那些变更的。不好的地方在于，运行以前的实现方式会消耗较多的成本。要想支持越多的版本类型，设计网关逻辑时就要越复杂。这样，就可以创造一个API永不停运的先例了。

每种情况不尽相同，如何处理这种从一个圈子转换到本系列中的另外一个圈子的情况：那就是，要了解你的用户。如果你想要尽力处理好客户关系，那么你就要做到，避免让客户做任何改变。如果用户在维护和更新（包括新特征和新功能两方面的更新）方面都做的比较好，那么他们会更加愿意放弃使用旧版本。

这就是为什么要在API管理策略以及API管理解决方案评估标准中要重点考虑用固定消费者门户网站的原因了。用户回顾API文件、相关记录以及样本代码的频率是多少？多久之后才能让用户养成一种操作习惯呢？API管理中所提供的资源将会成为其与用户沟通的关键工具。

本期报导的四篇有关API设计的文章，再加上之前几期关于API管理工具功能的几篇文章，对整个生命周期中，做出正确的API抉择都有很大的帮助。