虽然 API 已经存在了 50 多年，但它们在过去十年左右才开始成为主流，并引发了大量关于该技术的热议和兴趣。 拥有 API 具有许多优势，无论是面向公众的还是内部的。然而，各种组织和团队在踏上成功 API 之旅时仍然面临困难和问题。 我最近与 Chris Busse（APIvista (@busse) 的首席技术官）坐下来，深入探讨了 API 以及组织应该如何思考 API。APIvista 是一家专注于 API 开发和管理服务的公司，通过 API 帮助客户实现新的商业价值。凭借 20 多年的 IT 行业经验，Chris 对公司和组织应如何制定其 API 战略提供了宝贵的见解。
构建成功的 API
Chris 表示，成功的 API 需要像公司产品组合中的任何一流产品一样，得到同等的关注和重视。
“理解并对 API 消费者（即开发人员）抱有真正的产品管理同理心，就像您对待任何客户一样，这对于设计一个易于被采纳的优秀 API 来说至关重要。”
在处理 API 时应用产品管理原则和实践，是将 API 视为一流产品的第一步。产品经理了解他们的最终客户。API 也是如此。 了解 API 最终消费者的需求，并了解 API 如何融入他们的软件开发生命周期，对于构建可靠的 API 至关重要。在 API 开发和部署生命周期的每个阶段都考虑最终消费者的需求，将有助于引导 API 的开发朝着正确的方向前进。然后是用户体验同理心。设计 API 以及围绕它的工件和服务时，应始终将降低目标消费者的学习曲线作为首要任务。以最终用户为中心构建 API 是设计思维方法的基础。设计思维试图在最终消费者、业务和技术之间找到平衡。 API 也是如此，理想情况下，一个精心设计的 API 能够找到这种最佳平衡。这意味着随着 API 使用量的增加，业务价值得以实现和驱动，并且所实现的技术没有错误并符合公认标准。 通过产品管理和用户体验原则的正确平衡，最终消费者可以轻松地采纳和使用 API。像任何产品一样，采纳会带来更多的采纳。 Chris 认为，对于公共 API 来说尤其如此。我们看到很多时候，如果社区从 API 中获得很多价值，他们会积极参与并促进 API 的采纳，从构建文档到开发客户端 SDK。
上市速度是一个考量因素吗？
对发布日期有一个良好的估计很重要。很多时候，API 的上市速度和设计一致性之间存在权衡。虽然上市速度很重要，但不应导致 API 的首次发布效率低下且设计糟糕。 为此，Chris 建议识别一些最初的目标消费者，并在 API 的开发阶段尽可能多地获取他们的反馈。这将有助于 API 的良好首次发布，同时仍能满足发布期限。收集用户反馈的创新方式比比皆是，从组织黑客马拉松到识别试点客户。
需要注意的错误
这种策略中常见的一个错误是，组织仅根据这些初始客户的需求定制其 API，希望该 API 能够具有通用性以满足整个市场的需求。然而，事实证明，这些共同点反而导致了更多的差异。 因此，建议对这些初始客户的反馈持开放态度。制定具体的版本控制策略也有助于克服这一点。据 Chris 所说
“组织需要制定一个可靠的计划，说明何时以及如何向其 API 添加新变更，从而随着时间的推移满足更广泛的最终消费者群体。”
如果组织希望遵循某个理想目标，上市时间可能会受到影响。以超媒体 API 为例，它是 API 中的一个新标准级别。虽然发布基于超媒体的 API 会带来很多好处，但组织需要绝对确保最终客户具有消费这些 API 的成熟度和专业知识。请记住，通过采用新标准，发布者也期望其最终消费者具有一定程度的精通能力。 Chris 解释道：
“虽然他们可能在社交领域或数字用户体验领域拥有技术或尖端产品，但其中一些公司在将他们的 API 提升为一流产品方面经历了漫长的旅程，并且可能仍在这一旅程中。”
何时采用“设计优先”方法
如果组织足够成熟，能够坚持理想，那么设计优先是合理的。正如 Chris 所解释的，在很多情况下，API 设计被提出并确定后，API 的开发就开始了，但在开发过程中设计又被更新了。 这不是个例，如果各团队之间的沟通不够顺畅，这种情况可能会频繁发生。这种偏差只会增加团队的工作量，在某些情况下，还会导致团队之间产生大量的挫败感、敌意和不信任。 如果团队向开发团队提供 API 设计以使其能够提前开始实施 API，那么他们需要与开发团队保持开放的沟通渠道，并且必须建立高度信任。因此，尽管像 OpenAPI Specification（以前称为 Swagger Specification）、RAML 和 API Blueprint 这样的描述格式确实很有用，但将开发视为“设计优先”还是“代码优先”需要更多思考。因此，重要的是要经历 API 之旅，并找出哪种方法适合您的开发团队，因为纸上的理想并非总是在实践中最佳。 Chris 重申了设计一致性的重要性。无论采用何种方法构建 API，组织下不同产品和服务的不同 API 都应遵循相同的内部指南。 最终开发人员应该觉得组织提供的所有 API 都是由同一组织构建的。即使这些 API 彼此不交互，这一点也适用。 例如，像谷歌这样的公司，其拥有针对 YouTube、Google+ 和 Google Maps 等多个不相关产品的 API，但仍可遵循一些既定的内部标准，帮助开发人员轻松适应其 API。 Chris 向他的所有客户都推荐了这种展示的一致性。
衡量成功
API 投资面临的挑战之一是，最初的投资回报可能难以衡量。API 投资的成功可以通过组织获得重复业务的频率、合同续约的频率以及组织产品和服务受欢迎程度来衡量。所有这些自然会带来增长和收入，而且通常在事后，高管们会意识到这归功于公司将 API 视为一流产品的投资。 衡量成功的另一个良好指标是用户采纳度。需要在 API 的消费者体验上花费大量时间。Chris 和他的团队衡量的一项指标是“hello world”所需时间。这是 API 最终消费者成功发起调用所需的时间。文档和代码示例越好，最终用户进行身份验证和调用 API 所需的时间就越少。
设定正确的期望
组织必须意识到，消费者使用其发布的 API 也需要付出成本和努力。这些 API 还将与其他提供类似服务的 API 和产品竞争客户资源。因此，期望一旦 API 建成用户就会自动开始使用，这不是正确的方法。 像任何产品一样，API 需要时间和精力才能触达其目标受众。API 的采纳时间比许多人想象的要长，即使是最成功的 API 也需要 3-5 年才能达到其受欢迎程度。无论是从获得采纳，到致力于 API 的支持和维护，API 的各个阶段都有总拥有成本，并且要实现真正的成功，还有很长的路要走。 用 Chris 的话来说：
“不同公司可能处于其 API 生命周期中的不同阶段，期望它们以相同的势头达到终点是不切实际的。”
归根结底，每个 API 都旨在解决最终消费者的一个痛点。将价值归因于痛点以及 API 提供的解决方案，才是最终使其在技术和业务层面都取得成功的关键。
API 的未来
Chris 认为，人类与机器交互的界面将逐渐退居幕后，而计算将变得无处不在且无形。在过去的几十年里，我们已经看到界面发生了显著演变，从第一台巨型计算机到我们口袋里 7 英寸显示屏的 iPhone。同样的道理也适用于 API，它将演变出更好、更有趣的界面，供最终开发人员使用。
有兴趣了解更多？
Chris Busse 本周将在马萨诸塞州波士顿举行的 API 战略与实践大会 (APIStrat) 上发表演讲。了解更多。 在 Twitter 上关注 Chris Busse，他将在那里分享他对 API 领域的看法。 如果您有兴趣了解更多关于 APIvista 的信息，请访问他们的网站。