API 产品管理中的平台思维

已发表: 2022-03-11

大流行显着放大了组织采用数字优先战略的需求，这已不是什么秘密。 那些因其他组织目标而被取消优先级的数字化转型在一夜之间以前所未有的紧迫性转移到了前沿和中心。 根据 2020 年麦肯锡全球高管调查，尽管 COVID-19 带来了重大挑战，但公司将内部运营数字化并扩大数字产品组合的速度加快了数年。

这些数字化转型的核心是集成，由应用程序编程接口 (API) 促进。 API 曾经被简单地认为是在软件系统之间传输数据的“信使”或“中介”，现在被认为是数字生态系统的“连接组织”，为构建和利用 API 的组织提供了无限的集成和商机。 由于 API 具有独特的潜力，监督其开发的产品经理必须采用一种方法来释放其潜在价值，强调灵活性和可扩展性以确保完美的集成体验。

开发 API 可以帮助许多关键领域的企业

事半功倍

甚至在过去空前的一年之前，API 对组织的价值就已经有据可查，API 经济已经蓬勃发展了一段时间。 要了解当今的集成格局，探索最佳品种 (BoB) 哲学的起源会很有帮助。 在 1990 年代之前，软件供应商销售的企业资源规划 (ERP) 套件解决方案试图解决各种组织挑战。 这些套件越来越被视为笨重且不切实际，因为它们未能解决特定于组织的用例。 结果，供应商开始构建更集中的工具来解决一个功能领域的挑战，而不是试图为每个人做所有事情的更大的套件。 企业欢迎从各种更小、更专业的工具中进行选择的想法，并开始组装最符合其特定需求的个人解决方案集合。

连接点

随着 BoB 方法的兴起，集成成为产品战略的重要组成部分。 一个能够很好地解决某个业务领域问题的工具必须能够与可能与其一起使用的其他 BoB 产品很好地集成。 考虑一下 HubSpot，这是组织实施的销售和 CRM 软件，用于跟踪和优化他们的销售渠道和客户关系。 HubSpot 可以轻松与其他 BoB 软件集成，例如 DocuSign（数字签名）、Twilio（电子邮件/短信通知）和 Zendesk（客户支持），而无需客户工程团队的额外开发。

API 允许软件工具相互集成。

对互补工具无缝插入的需求伴随着整个行业向拥抱开放而不是限制系统之间交互的转变。 在此过程中，产品支持的集成数量成为值得营销的指标。

平台主张

然而，集成的真正价值超出了它们协调不同工具和系统的能力。 在最好的情况下，API 是将产品转变为平台的集体机制。 根据定义，产品是具有特定应用的工具； 因此是“应用程序”。 他们创造多种价值主张的能力有限，进而无法创造多种收入来源。 另一方面，平台以不同的方式增加价值：通过提供可以构建大量产品的基础设施层。

API 通过利用利用它们的第三方的专业知识开辟新的业务渠道。 消费开发者可以设计一个房地产应用程序，使用 Google Maps 的 Places API 来帮助用户寻找房屋，或者他们可以利用 Skyscanner 的 Flight API 和 Expedia 的 Hotel API 创建一个专门针对特定地点旅行的生态旅游网站。 这些开发人员和外部合作伙伴通过访问可以适应其业务的现有数据和服务而受益，而像 Expedia 这样的 API 所有者扩大了他们的覆盖范围并利用如果他们继续仅在其产品上列出酒店就不会存在的机会。

使其模块化

对于产品领导者来说，制定成功的 API 策略需要将思维方式从产品思维转变为平台思维。 这意味着以模块化、开放式的方式构建产品，允许重新组合其功能，并优先考虑消费开发人员的灵活性。 想想宜家货架系统，客户可以通过不同的方式购买、组装和定制，以满足各种需求。 优秀的 API 产品经理会看到 API 的本质：用于扩展业务和发展有价值的合作伙伴关系的工具。 认识到这种潜力意味着实施最佳实践以确保采用。

在开发 API 时，最好考虑模块化和灵活性。

取悦开发者

如果一个可靠的 API 策略有一个基本支柱，那就是开发人员体验 (DX)。 对于 API 集成，“客户”产品经理需要取悦正在消费的开发人员。 这些是最终调用/集成 API 的用户，是可以帮助实现产品到平台愿景的潜在合作伙伴。 将他们的体验贴上“DX”而不是“UX”的标签承认他们不是典型的最终用户——他们在技术上明显更熟练。 为了同情他们，了解他们的具体需求和期望至关重要。

最佳实践

以下内容虽然不代表详尽的列表，但却是构建一流 API 的基本实践，可确保为消费开发人员提供无摩擦、一致、可预测的集成体验。 产品经理应该以可扩展的方式设计 API，定义最佳实践框架并将其发布为团队在构建新 API 时可以参考的文档。

一致的命名约定和端点

为明确识别 API 的性质和用途的 API 端点建立一致的命名约定可以消除歧义，并有助于实现积极且可预测的 DX。 最好为所有 API 选择一个通用的基本 URL，并为尾随 URL 选择一个避免行话和缩写的框架。 Nordic API 提供了一个有用的端点命名提示列表。

详细的成功和失败响应结构

开发人员希望并期望熟悉的数据对象和状态代码用于成功和失败响应。 这意味着成功场景的 2xx 状态代码、客户端故障的 4xx 代码和服务器端错误的 5xx 代码。 然而，特异性是关键。 对“发送电子邮件”API 的调用只会返回 4xx 响应而没有额外的信息，这会导致开发人员体验不佳，因为它只是确认错误出现在客户端请求中，而没有提供关于究竟出了什么问题的额外信息。

 { "status": 400, "message": "incorrect request" }

相比之下，以人类可读格式和唯一错误代码形式提供特定详细信息的响应可以帮助开发人员快速决定如何纠正错误场景，编写代码来解决问题，并重试 API 调用。

 { "status": 400, "message": "To recipient not specified", "code": 21221 }

为了获得最佳 DX，响应结构和传达状态的密钥应该在 API 之间保持一致。 例如，上面的错误代码字段在每个 API 中都应始终称为“代码”，而不是某些 API 中的“代码”和其他 API 中的“错误代码”。

可配置的速率限制

速率限制通过确定用户在单个时间单位内可以调用它的次数来控制 API 的可访问性。 过高的速率限制会使系统充满无法管理的请求，从而降低性能，而不合理的低速率限制可能导致待处理的事务在用户系统中排队。 两者都导致糟糕的DX。 在设计 API 时，最好允许可以根据特定业务案例和环境调整的速率限制。 例如，大批量客户可能确实需要更频繁地调用 API。

为了最好地确定适当的速率限制，首先根据调用 API 的频率和数量将 API 分为有意义的类别是有帮助的。 例如，配置主要客户数据（配置文件/帐户创建）的 API 调用频率较低，可以处理较低的速率限制，而事务 API（“创建订单”、“发送电子邮件”）调用频率更高，需要更高的速率限制。 为不同的用例建立类别或层级可以实现更可靠和可扩展的 API。 有关明确定义的速率限制的示例，请参阅 Slack 的 API 文档。

API 产品经理应该致力于创造令人愉快的开发人员体验。

综合文档

文档用作 API 的用户手册。 它清楚地向开发人员阐明了 API 的作用、使用方法以及对它的期望。 好的文档以清晰易懂的语言编写，内容详细且具有交互性，并提供大量演示和代码片段以简化集成。 通过这种方式，它有助于轻松入职并加快首次 Hello World (TTFHW) 时间，这是一个重要指标，表示开发人员可以多快地成功调用他们的第一个 API。

文档应清楚地确定 API 请求中的哪些字段是强制性的，哪些是可选的，以及这些字段的最小和最大长度和数据类型。 从本质上讲，它应该包括为消费开发人员设定期望和消除障碍所必需的一切。 例如，在他们的系统中创建数据库模式的开发人员不应该在以后调整表中列的长度，因为文档没有指定参数。

API 文档不仅可以作为消费开发人员的可靠参考，而且可以作为 API 本身的营销工具，从而提高采用率。 通常，第一个遇到 API 文档的人是面向业务的利益相关者，他们在产品评估的初始阶段浏览它。 因此，它不仅应该包括有关 API 技术元素的详细信息，还应该清楚地阐明 API 实现的业务用例。

市场上有许多工具可以帮助生成全面的 API 文档。 查看诸如 Stripe 等高质量文档的示例也很有帮助。

把它放在一起

集成代表了一个包含许多组件的广阔领域，但了解良好 API 的核心原则是制定可靠策略的基础。 API 不仅仅是系统连接器。 它们是扩展数字网络的基石，也是开辟新收入来源和释放未开发价值的关键。 正因为如此，一个成功的 API 策略不仅仅是构建产品。 这是关于建立潜力。 API 产品经理必须采用平台思维方式，并优先考虑那些能够让潜在合作伙伴顺利采用的因素，这些潜在合作伙伴随后可以使用他们的 API、集成并使用它运行。