虽然 API 已经存在了 50 多年，但它们只是在过去十年左右才成为主流，围绕这项技术有很多讨论和兴趣。 拥有 API 有很多优势，无论是面向公众还是内部的。 然而，许多组织和团队在踏上成功 API 的旅程时仍然会遇到困难和问题。 我最近与 APIvista 的 CTO Chris Busse 坐下来，进一步讨论 API 以及组织应该如何考虑 API。 APIvista 是一家专注于 API 的开发和管理服务公司，帮助客户通过 API 提供新的商业价值。凭借在 IT 行业 20 多年的经验，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 规范（以前称为 Swagger 规范）、RAML 和 API Blueprint 这样的描述格式确实满足了很好的需求，但将开发方法视为“先设计”或“先代码”需要更多思考。因此，重要的是要经历 API 之旅，并找出哪种方法适合您的开发团队，因为纸上的理想并不总是实践中的最佳选择。 Chris 重申了 设计一致性的重要性。无论构建 API 的方法如何，组织下不同产品和服务的不同 API 都应具有相同的内部指南。最终开发人员应该感觉到组织提供的所有 API 都是由同一个组织构建的。即使这些 API 彼此不交互，情况也是如此。 例如，像 Google 这样的公司，拥有针对 YouTube、Google+ 和 Google Maps 等多个不相关产品的 API，仍然可以遵循一些内部标准，帮助开发人员轻松适应其 API。这种呈现方式的一致性是 Chris 向所有客户推荐的。
衡量成功
API 投资面临的挑战之一是，最初的投资回报率可能无法衡量。API 投资的成功可以通过组织获得回头客的频率、合同续签的频率以及组织的产品和服务获得的受欢迎程度来衡量。所有这些自然会导致增长和收入，而且通常，事后看来，管理人员会意识到这是因为公司投资于将 API 视为一流产品。 另一个衡量成功的良好指标是用户采用率。需要花费大量时间在 API 的消费者体验上。Chris 和他的团队衡量的一件事是“hello world”的时间。这是 API 的最终消费者成功调用 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 的信息，请在此处查看他们的网站。