关于 API 的 11 大误解

[本文由 Paul Bruce 撰写。]

API 渗透到互联世界，技术和非技术专业人员都在使用它。在某些时候，我们都使用 API，构建它们、销售它们、维护它们并使用它们。由于存在如此多的观点和意见，误解很快就会出现，从而使决策过程蒙上阴影，并阻碍 API 交付业务改进的执行。

本文着重于消除一些关于 API 生命周期的最常见的误解，这样您就不会在自己的流程中受到错误信息的摆布。本文中的要点由 SmartBear 的首席技术官 Ole Lensmar 根据他最近在 AppsWorld North America 上关于该主题的演讲慷慨借用。

误区 #11：API 只能解决技术问题

API 没有按钮和华丽的图形，但这并没有降低它们对非开发人员的重要性。业务决策者都需要知道 API 可以通过划分工作项目来加快交付时间，提供建模良好的通过电子表格将数据提供给业务用户，甚至在数据经济中充当他们自己的产品。

如果您的组织将 API 归类为一种令人讨厌的技术资产，仅为开发人员的利益而存在，您可能会发现，与合适的非技术业务所有者（例如 CTO 或 IT 主管）坐下来只是您需要打破这种误解的开端。花 15 分钟回顾 API 对您组织中的每个人来说都是一件大事的非技术原因可能正是医生所要求的。

误区 10：API 对企业来说是次要的

即使 API 被视为只是您组织的“粘合剂”，或者如果您没有发布公共 API 而不是在内部使用它们，系统之间的集成也是企业健康和功能的重要组成部分。随便问问如果财务部门没有依赖于 API 的一些关键集成，您将看到一切如常的业务将以多快的速度停滞不前。

同样，许多组织在幕后使用某种形式的传统数据库方案。您不会将数据库中的代码和查询称为业务的“次要”，因此当涉及到连接组织使用的系统的 API 时，您也不应该这样做。每家公司都是信息时代的科技公司，了解业务模型背后的工作组件的重要性可以保护您在需要进行更改时免受错误或不明智的决策的影响。

误区 #9：他们的 API 将始终可用

您认为刚刚集成的第 ³ 方 API 会永远存在吗？ API 公司，尤其是那些只生产 API 的公司，除非拥有健康的生态系统和领导力来支持，否则很快就会崩溃。您必须明智地选择您的第 ³ 方集成，因为如果它们碰巧倒闭，您可能会陷入困境争先恐后地寻找另一个满足您的技术需求和财务要求的 API 提供商。

如果您认为与 Google API、Twitter 和 Amazon 等大公司集成是安全的，您猜怎么着？你不。虽然他们不太可能经历灾难性的崩溃，这些公司确实会定期更改其公共 API 模式。如果您不注意，您与大型提供商的集成可能会因这些更改而中断。同样重要的是要考虑到，作为无数其他 API 消费者之一，您对流行 API 的权限要小得多，因此您对这些 API 如何更改的投票（如果您甚至获得投票）可能远不如您与真正依赖于您对其服务的订阅的 API 提供商。

误区 #8：我们的 API 无法被黑客入侵

仅仅因为您还没有被黑客入侵，或者您已经采取了您认为足够的措施来保护 API 的滥用，请放心，您的 API 将成为恶意用户和不良行为者进行黑客攻击的目标。

它一直在新闻中发生——想想 Moonpig 漏洞和对 Uber 和 Tinder 等公司的持续攻击，这是一个明显的迹象，表明公共 API 与任何其他网络或移动应用程序一样构成安全问题。当然，Uber 的人在公开发布他们的 API 之前就考虑过安全性，但是通过苦力和恶意，黑客仍然找到了一种滥用他们的 API 的方法。如果您要发布公共 API，请务必及时检查您的 API 是否符合指南，例如 REST 或 SOAP Web 服务的前 10 名 OWASP 扫描。或者您可以使用这样的工具保护您的 API。

误区 7：他们的 API 无法被黑客入侵

当您考虑与 3 ^rd 方 API 集成时，上述每一点都适用。如果他们没有零日响应政策，您可能需要重新考虑通过他们的 Web 服务信任您的数据。还要警惕那些在某个时间点提供合规性但不愿意向您详细介绍其持续安全流程的 API 提供商。如果他们不能始终确保他们吹捧的一致性，那么他们甚至可能不知道自己已被破坏。

不相信任何人。保持警惕。要求别人也一样。

误区 #6：SSL + OAuth 就足够了

彻底的安全性永远不会锁定在一层，因此重要的是要考虑到多层安全性，以阻止黑客攻击并减少单点漏洞。过于依赖单一诸如 SSL 作为传输安全机制或 OAuth 作为授权模式之类的层，在不考虑网络级或数据级漏洞的情况下，将使黑客很容易与您建立的少数机制一起玩，直到他们找到未受保护的要利用的系统方面。

只需考虑不记名令牌漏洞利用，因为如果没有 SSL，整个身份验证过程都是伪造的。还有其他常见漏洞，但首要主题是您保护 API 的方法必须是多层的。使用 OAuth + SSL 可能是朝着正确方向迈出的重要一步，尤其是当您使用像基本身份验证这样神秘的东西时，但这只是一步。确保将下一个作为部署或维护计划的一部分。

误区 5：元数据不好

简而言之，认为元数据不好的想法显然是错误的。元数据只是目的主要数据之外的“其他信息”。例如，Microsoft Office 等常见程序会产生大量元数据；主要数据是您包含在文档或电子表格中的内容，而元数据是作者和来源信息、基础数据源的凭证以及其他相关信息在整个创建过程中与文档一起使用，但通常不会在文档本身中公开。

API 元数据可以被认为对 API 的主要功能至关重要，但此数据以非标准方法暴露给主要数据的交付方式。元数据可以自定义标头的形式存在，以减少将新功能烘焙到现有 HTTP 主体模式或规范中的过程。只要使用 API 的每个人都理解为什么“元数据”与传统“数据”分开存在，所有元数据就是数据。明智地使用它。

误区 #4：您需要遵守 REST 原则

最具约束力的商业实践之一是严格遵守某种形式的指导方针，即使它们对特定情况没有意义。休息原则很好，但是 REST 缺乏非常重要的东西，比如内置的正式模式定义和用于执行安全性（WS-Security、WS-Trust）、分布式事务和异步处理（JAX-WS）的附加标准。

无论您拥有 SOAP 还是 REST 服务，您都应该愿意考虑应用架构原则所依据的上下文。使用 REST 作为如何构建 API 的标准错过了 REST 的要点：基于对领域的深思熟虑构建合适的东西。

误区 3：自上而下创建 API 仅适用于复杂的架构

不是这样！ API 有各种形状和大小，尤其是在企业中。一次一个地重写基础设施的一小部分通常是团队从单一的 Web 服务方法迁移到更具可扩展性、可维护性的模型（如微服务）方面取得进展的唯一方法。

如果您正在尝试划分一类在您的基础架构中具有主题性的问题，那么是的，自上而下的方法通常是一个很好的尝试……在白板上……与您的团队的其他成员一起尝试。最有效的 API 是在设计时考虑到消费者的，这对于喜欢在迷失实现细节之前先考虑设计的人来说是个好消息。即使是最小的 API 也应该经过深思熟虑，抓住每一个机会采用自上而下的 API 设计方法可以帮助改善消费者体验和 API 基础设施的整体景观，一次一个端点。

误区 #2：没有人使用 SOAP

这可能是当今存在的最普遍的 API 误解之一，但它严重歪曲了当前的 API 经济。许多组织在 REST API 出现之前就已经存在，并且经历了一个又一个的编程时代。 SOAP 是早期 SOA 时代的唯一选择，获得了企业的大规模采用以及多年的生态系统支持和工具。现在，当然，对于旨在以形式换取敏捷性的应用程序和设备，SOAP 已经发生了转变。但是，无论我们多么努力地前进，我们的世界大部分都是建立在 XML 之上的。