众所周知，大流行大大增加了组织接受新冠病毒的需求 数字领先战略. 原本被其他组织目标所忽视的数字化转型在一夜之间转移到了前台和中心, 以前所未有的紧迫性. 根据2020年 麦肯锡全球高管调查, 公司加快了内部运营数字化的速度，并在数年内扩大了数字产品组合, 尽管2019冠状病毒病带来了重大挑战.

这些数字化转型的核心是整合, 由应用程序编程接口(api)提供便利. 曾经被简单地认为是在软件系统之间传输数据的“信使”或“中介”, api现在被认为是结缔组织数字生态系统, 为构建和利用它们的组织提供无限的集成和业务机会. 因为有独特的潜在api， 产品经理 监督其发展必须采取一种释放其潜在价值的方法, 强调灵活性和可扩展性，以确保完美的集成体验.

事半功倍

甚至在过去前所未有的一年之前，api对组织的价值就已经很好了 记录，和 API经济 曾经繁荣过吗 time. 的起源是有帮助的，可以理解今天的集成环境 最佳犬种 (BoB)哲学. 90年代以前, 软件供应商销售企业资源计划(ERP)套件解决方案，试图解决各种各样的组织挑战. 越来越多地, 这些套房被认为是笨重和不切实际的, 因为他们没有处理特定于组织的用例. 结果是, 供应商开始构建更集中的工具来解决某个功能领域的挑战, 而不是试图为每个人做所有事情的更大的套房. 欢迎企业从各种小意念中选择, 更专业的工具，并开始组装最适合其特定需求的单个解决方案集合.

串连点点滴滴

随着BoB方法的发展，集成成为了产品策略的关键部分. 一个非常擅长解决某个业务领域问题的工具必须能够与其他可能与它一起使用的BoB产品很好地集成. 考虑 HubSpot的, 由组织实施的销售和CRM软件，用于跟踪和优化其销售管道和客户关系. Hubspot的 很容易与其他BoB软件集成，如 DocuSign (数字签名), 为什么Twilio (电邮/短讯通知)，以及 Zendesk (客户支持)，而不需要客户工程团队的额外开发.

对互补工具之间无缝连接的需求，伴随着整个行业转向拥抱开放，而不是限制系统之间的交互. 在路上的某个地方, 产品支持的集成数量成为值得营销的指标.

平台主张

API对产品经理的真正价值, 然而, 超出了他们协调不同工具和系统的能力. api是将产品转变为平台的集体机制. 这就是平台产品管理发挥关键作用的地方. 产品s, by definition, are 工具 that have a specific application; hence “apps.“他们创造多种价值主张的能力有限, 通过扩展, 多种收入来源. 平台, 另一方面, 以另一种方式增加价值:提供基础设施层，在此基础上可以构建许多产品, 并实现更全面的产品管理方法.

api通过利用第三方的专业知识来打开新的业务渠道. 消费开发商可以设计一个房地产应用程序，使用 谷歌地图的位置 api来帮助用户找房子，或者他们可以利用 Skyscanner的 飞行api及 Expedia的 酒店api创建一个生态旅游网站，专门旅游到一个特定的位置. 这些开发人员和外部合作伙伴通过获得对现有数据和服务的访问而受益，他们可以根据自己的业务进行调整, 而像Expedia这样的API所有者，如果他们继续这样做，就不会有盈利机会, 说, 只在他们的产品上列出酒店.

模块化

一个成功的API产品开发策略需要从产品思维转向平台思维. 这意味着以模块化方式构建产品, 开放式时尚，允许它们的功能重新组合，并优先考虑消费开发人员的灵活性. 想想宜家的货架系统, 哪些客户可以购买, 组装, 并以不同的方式定制，以满足各种需求. 优秀的API产品经理看到API的本来面目:扩展业务和发展有价值的伙伴关系的工具. 认识到这一潜力意味着实现最佳实践以确保采用.

让开发商高兴

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

最佳实践

以下, 尽管这绝不是一个详尽的清单, 构建确保无摩擦和一致的一流api的基本实践是什么, 为消费开发人员提供可预测的集成体验. 接受API作为产品的概念是至关重要的, 因为它赋予api与其他产品相同的关注. 产品经理应该以可扩展的方式设计api, 定义最佳实践框架，并将其发布为团队在构建新api时可以参考的文档.

一致的命名约定和端点

为API端点建立一致的命名约定，明确标识API的性质和目的，消除歧义，并有助于实现积极和可预测的DX. 最好为所有api选择一个通用的基础URL，并为后面的URL选择一个框架，以避免术语和缩写. 北欧api提供了一个有用的 提示列表 用于命名端点.

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

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

{
   “状态”:400年,
   "message": "错误的请求"
}

与此形成鲜明对比的是, 以人类可读的格式和唯一错误代码的形式提供具体细节的响应可以帮助开发人员快速决定如何纠正错误场景, 编写代码来解决这个问题, 并重试API调用.

{
   “状态”:400年,
   "message": "收件人未指定"，
   “代码”:21221
}

求最优DX, 响应结构和通信状态的密钥应该在api之间保持一致. 例如, 上面的错误代码字段在每个API中都应该被称为“代码”, 而不是在一些api中使用“code”，在另一些api中使用“errorCode”.

可配置速率限制

速率限制通过确定用户在单个单位时间内可以调用API的次数来控制API的可访问性. 速率限制过高会使系统充斥大量无法管理的请求，从而降低性能, 而不合理的低速率限制可能导致用户系统中的挂起事务排队. 两者都导致了较差的DX. 在设计api时，最好考虑速率限制 调整 基于特定的业务案例和环境. 例如，大容量客户可能确实需要更频繁地调用api.

以最好地确定适当的速率限制, 首先根据api被调用的频率和数量将它们分成有意义的类别是有帮助的. 例如, 配置主要客户数据(配置文件/帐户创建)的api调用频率较低，可以处理较低的速率限制, 而事务api(“创建订单,“发送电子邮件”)被更频繁地调用, 要求更高的速率限制. 为不同的用例建立类别或层可以获得更可靠和可扩展的api. 有关明确定义的速率限制的示例，请参见 Slack的API文档.

全面的文档

文档是API的用户手册. 它清楚地向开发人员阐明了API的作用、如何使用以及期望从中得到什么. 好的文档写得很清楚, 易懂的语言, 详细且具有互动性, 并提供了大量的演示和代码片段，使集成更简单. 以这种方式, 它便于登机和快速到达第一问候世界(TTFHW)。, 这是一个重要的指标，表示开发人员能够多快地成功调用他们的第一个API.

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

API文档不仅可以作为消费开发人员的可靠参考，还可以作为API本身的营销工具，从而提高采用率. 经常, 第一个遇到API文档的人是面向业务的涉众, 谁在产品评估的初始阶段浏览它. 因此，它不仅应该包括API技术元素的细节，还应该清楚地阐明API使之成为可能的业务用例.

有很多 工具 可以帮助生成全面的API文档. 回顾高质量文档的示例，如 条纹的，也很有帮助.

将一切结合在一起

集成代表了一个包含许多组件的巨大领域, 但是理解一个好的API的核心原则是开发一个可靠的策略的基础. api远远不仅仅是系统连接器. 它们是庞大数字网络的基石，也是打开新收入流和释放未开发价值的关键. 正因为如此，一个成功的产品 管理API策略 isn’t just about building products; it’s about building potential. API产品经理必须具备平台思维，并优先考虑能够让潜在合作伙伴顺利采用API的因素, 集成, 跟着它跑.