原文链接：https://document360.com/blog/internal-vs-external-apis/
内部和公共 API 在受众和使用场景上有所不同。公司内部利益相关者使用内部 API 是其工作职责的一部分，目的在于提高内部生产力和效率。而公共 API 则可以创造收入，树立开源产品的公司品牌，或着持续改进 API。
公共 API
企业通过公共 API 为大众提供一个标准化且安全的接口，用于访问其数据来构建应用程序。这些 API 向公众利益相关者开放，如外部开发人员、第三方供应商和客户，并支持通过互联网使用 HTTP 协议进行访问。外部 API 通常会提供特定的功能或服务，如访问数据或执行事务。
关于外部 API 的一些要点：
- 对公众开放
- 比内部 API 更多地用于创建用户界面
- 创造收入或提高品牌知名度
- 收集使用情况指标以改进 API
- 管理后端组件之间的交互
- 有助于与其他业务应用程序集成
内部 API
内部 API 可以提高运营效率。公司内会使用内部 API 来访问公司未向公众公开的敏感内部系统和数据。与公共 API 不同，内部 API 的功能高度专业化，并不适用于一般用途，因此内部 API 很少用于创建用户界面。
公司使用内部 API 作为由不同组织开发团队构建的组件的接口，这些团队在不同的组件上工作。此外，它们还使用内部 API 作为允许组件之间通信的接口。公司还会创建 API 作为独立组件，以实现特定功能，而不仅仅是作为“连接器”。
关于内部 API 的一些要点：
- 不在互联网上公开
- 仅在公司或开发团队内部创建和使用
- 可能为内部利益相关者提供敏感数据的访问权限
- 专注于特殊的功能，而不是通用的
- 用于连接微服务架构中的组件
- 处理后端服务，而不是创建用户界面
公共 API 的优势
- 收入： 通过向第三方应用开发人员公开数据，公共 API 有可能创造收入。
- 品牌知名度： 无论 API 是否产生收入，企业将其 API 公开，都可以提高其品牌知名度。此外，由于 API 适合普通用户，因此其覆盖范围可以扩展到开发人员以外的业务利益相关者和公民开发人员。
- 社区建设： 企业可以围绕其公共 API 建立一个不断发展的公司。社区可以为每个版本的新功能提供建议，并提供一个持续的反馈循环。
- 创新： 通过公开你的数据，第三方可以以 API 开发人员最初并未打算的方式进行创新。第三方开发人员可以将你的产品与其他业务应用程序集成，从而丰富你的应用程序生态系统。
- 可扩展性： API 为第三方提供了一个标准的接口来访问公司的数据。标准 API 允许公司在不花费大量资源支持新用户的情况下进行扩展。统一的接口还意味着公司不需要创建难以维护的定制解决方案。
公共 API 的缺点
- 安全风险： 如果公共 API 没有得到充分的监控和安全保障，就会存在安全风险。虽然可以采取必要的安全措施，但始终存在用户利用 API 中的漏洞获取数据访问权限的风险。因此，公司应该有一个透明的流程来报告安全漏洞并进行安全检查。
- 依赖第三方： 使用 API 构建的应用程序的受欢迎程度决定了 API 是否成功。当更多的客户使用 API 时，它的价值和采用率就会增加。
- 复杂性增加： 内部 API 是根据公司的内部需求量身定制的，而公共 API 必须满足普通受众的需求，并支持多种用例和第三方应用程序。
- 支持和维护： 公共 API 需要持续的支持和维护，以确保稳定性、安全性和可靠性。
- 法律和监管合规： 公共 API 必须遵守内部 API 不受约束的法律和监管合规要求。保持合规性增加了 API 维护的复杂性。
内部API的优点
- 更强的安全性： 与公共 API 不同，公司将内部 API 托管在防火墙后的内部网络上。因此你可以将访问权限仅限于公司内部及公司内部使用的应用程序的授权用户。
- 更好的控制： 内部 API 使公司能够控制在组织内谁可以访问哪些功能和数据。
- *灵活性： *你可以专注于创建符合公司特定需求的 API。
- 降低成本： 内部团队可以创建 API 来解决他们的问题，并且通过不采用第三方 API 来节省资金。
内部 API 的缺点
- 曝光有限： 由于 API 不对公众开放，公司无法利用机会产生收入、提高品牌知名度或收集使用情况指标以反馈到API的改进中。
- 资源有限： 由于内部 API 不产生收入，因此它们通常需要更多资源来支持和发展。与公司的盈利产品相比，它们通常不被优先考虑，这会导致 API 无法得到维护和更新。随着时间的推移，不受支持的内部 API 会失去效力，因为内部开发人员不再信任它们的输出，并可能会选择一个维护得更好、执行相同功能的第三方 API。这就是为什么内部 API 应该尽可能简单，以便更容易维护。
- 宣传度低： 导致资源有限的另一个因素是需要更多的宣传，特别是对业务利益相关者而言。内部开发人员需要向业务利益相关者和管理人员传达内部 API 的价值，以便他们能够提供维护它所需的资源。
- 用例有限： 内部 API 通常连接对于非开发人员利益相关者来说价值较低的后端资源。但是，在业务用户的支持下，内部 API 可以进一步发展，以支持组织中的其他类型的用户。
- 缺乏创新： 如果内部 API 不对公众开放，它们可能永远无法实现其全部潜力，因为它们不允许第三方以新的和创造性的方式使用它们。非创新的内部 API 可能会促使开发人员采用类似的公共 API。
为什么 API 管理至关重要？
API 管理对于内部和公共 API 都至关重要。在我们展示如何以不同方式管理它们之前，让我们回顾一下为什么 API 管理是这么关键。
什么是 API 管理？
API 管理是指设计、发布、监控和保护 API，开发人员、客户和其他利益相关者使用这些接口来访问公司的软件和数据。
- 安全性： API 管理有助于实施身份验证和访问控制，加密数据，并监控安全性。这些手段可以保护敏感数据并防止未经授权的访问。
- 可靠性： API 管理通过提供相关的使用方式、用户行为和性能指标的实时数据的分析，确保 API 的可靠性。因此公司可以识别潜在问题，如性能瓶颈和错误，并在它们成为重大问题之前解决它们。
- 可扩展性： 开发人员工具和文档使第三方开发人员能够轻松使用 API。此外，它具有可扩展性，因为只要有适当的资源，API 就可以变成自助服务。
- 节约成本： 提供标准化的 API 是低成本且高效的，因为你不需要为每个客户维护定制集成。
API 管理的最佳实践
API 管理涉及几个关键步骤，可以帮助确保 API 的安全性、可靠性和可扩展性。以下是一些管理 API 的最佳实践。
- 有效设计 API： 最好设计可靠且可扩展的 API。定义端点、数据格式和身份验证都是有效 API 设计的一部分。
- 记录 API： API 用户需要资源来帮助他们理解 API，包括参考文档、概念文档、代码示例、教程和其他开发工具。
- 测试 API： 必须对 API 进行严格的测试，以确保其按预期工作。测试包括功能测试、性能测试和验收测试。
- 发布 API： 发布将 API 暴露给其预期用户，无论是内部还是外部用户。公共 API 通常使用 API 管理平台发布，该平台向客户暴露 API。这些平台为客户提供对资源（如文档和开发人员工具）的访问，以帮助他们理解和体验 API。
- 发现 API： 有一种误解，认为可发现性只对公共 API 至关重要。然而，API 必须易于被内部和外部利益相关者发现。不过创建用户界面来搜索和过滤 API 需要内部 API 通常需要的更多资源。因此，企业应考虑内部 API 是否有可能在未来变得 “公开”，如果是这样，那么应适当投资其可发现性。
- 保护 API： 要实现 API 的安全性，需要实施适当的身份验证和访问控制。对于公共 API，API 网关通过验证用户、加密传输中和静态的数据以及监控安全威胁来管理 API 的安全性。
- 管理访问权限：你必须实施授权策略，以控制谁可以访问你的 API 以及他们被分配了哪些权限。
- 监控 API： 对于公共 API，你可以利用 API 管理平台的分析功能来收集 API 性能相关实时使用数据。这些平台可以预先识别问题，如错误、性能瓶颈和安全威胁。
- 收集分析数据： 你应该捕获并分析数据，以深入了解使用模式、用户行为和性能指标。因此，你可以利用这些见解来优化性能并改善开发人员体验。
- 更新 API：为了与你的 API 用户建立信任，你应该定期更新 API，以向用户表明你的 API 维护良好并采纳了反馈。
内部 API 与公共 API 的不同和管理策略
既然我们已经了解了 API 管理的基础知识，现在让我们来讨论一下内部 API 与公共 API 的管理有何不同。
- 身份验证和访问控制： 公共应用具有更严格的身份验证和访问控制。公共 API 需要集成如 OAuth 2.0 等服务进行身份验证，并且在许多情况下，要求用户注册API密钥以识别他们的请求。
- 文档和开发者工具： 公共 API 需要为开发者提供更多的资源，如详尽的文档和开发者工具。此外，公共 API 往往需要满足非技术的业务利益相关者的需求，而内部 API 则通常为后端服务所用。
- 货币化： 如果公共 API 用于创收，则需要一个货币化模型，这需要另一层管理层。通常情况下，收费是基于 API 的使用情况、分级定价计划或收取第三方应用所产生收入的一部分。
- 性能和可扩展性： 公共 API 必须具有高性能和可扩展性，以同时处理众多平台用户。另一方面，内部 API 的使用者数量通常比公共 API 少得多，因此它们能够承受的压力较小。
- 分析和监控： 收集分析数据对于改进公共 API 至关重要，但这又增加了另一层复杂性。内部 API 虽然也能从分析中受益，但相对较少。内部 API 更加可预测且可控。
文档编写
编写内部 API 文档与编写公共 API 文档略有不同。
内部 API 文档通常包含更多细节，因为它特定于内部开发团队的技能和知识。
公共 API 文档的读者群体更加广泛。企业在撰写公共 API 文档时会考虑到用户不同的技术能力。公共 API 文档中包括（而内部 API 文档中不包括的）的主题，包括身份验证要求、速率限制、数据格式和错误代码。
公共 API 文档提供了更多的安全考虑，如用户身份验证和存储敏感数据。另一方面，内部 API 更加安全，不需要构建与公众交互的架构。因此重点在于更多地是如何使用 API 连接内部系统组件。
企业将公共 API 文档发布到开发者门户，该门户为公众提供了解可用 API 的在线资源。内部 API 文档通常使用 Swagger 等工具发布，并且仅在公司内网上可用。
公共和内部 API 文档在提供的细节量、提供的安全信息以及如何访问文档方面有所不同。
总结
API 是公开的还是内部的取决于其受众和使用方式。每一种都有其优缺点，因此企业在开发 API 时必须要权衡这些优缺点。
公共 API 有可能创造收入，提高品牌知名度，促进社区建设与创新，并增强可扩展性，但代价是牺牲安全性、增加复杂性和持续的支持与维护。
内部 API 提供了更强的安全性、更高的运营效率、更多的访问控制和更大的灵活性，但代价是曝光有限、资源减少、可见性有限以及对更广泛受众的实用性降低。
最终，公共 API 具有与公众建立反馈循环机制以改进它们的优势。
想要克服内部 API 的缺点，需要公司优先考虑维护这些功能，以及考虑产生收入的产品如何依赖它们。内部 API 需要倡导它们值得投入资源，以获得业务利益相关者和管理者的支持。公司在分配资源时应考虑该 API 未来是否有潜力成为公开的。
更多 API 管理及 API 全生命周期相关内容可以在我的 Notion 查看，我将会持续更新：API 全生命周期管理资料
