人们很容易把所有API混为一谈，认为它们都是一回事。但这种说法并不准确。
诚然，它们都是应用程序接口（API），且都能在无需重写代码的情况下，弥合不同产品或服务之间的鸿沟，从而实现无缝集成。虽然每个人都可以自由设计和构建软件，但几乎所有的API都（至少部分）遵循着明确定义的规范。这些准则旨在保持一致性，并维护API的核心目标：简化集成与通信。
如果您有兴趣设计 API、与 API 进行集成，或者只是想了解这些令人兴奋的软件组件，那么请继续阅读。我们将探讨最流行的 API 风格，并分析它们各自的独特之处。
不过请记住，所有风格都有其优缺点。在选择时，应根据您的具体用例、用户需求以及开发团队的实现能力来做出决定。
关于使用场景，值得一提的是，API 可以是公开的、仅限合作伙伴使用的，或是完全内部的。这一首要区分因素为许多需要开发的功能和特性设定了标准：数据如何存储和共享、凭证如何处理、API 需要处理多少流量等。
如您所见，以下架构风格虽可应用于这三种场景，但某些组合比其他方案更合理。
这是当今最常见的 API 类型，也是我们构建 WebScrapingAPI 所采用的风格。该缩写代表“表征状态转移”（REpresentational State Transfer），其设计原则是：当您作为客户端发起请求时，API 会返回所请求资源状态的表征。
RESTful API 高度依赖于 HTTP 基础设施。由于互联网普遍主要使用 HTTP，REST API 因此具有易于理解、集成和使用的优势。
这种风格还由一组 API 必须遵守的约束条件所定义。虽然这听起来可能有些麻烦，但这些约束确保了 API 能够以可预测且有用的方式运行。总共有六条约束，具体如下：
我们已在 Medium 上发布了一篇关于这些约束条件的完整文章，请阅读该文章以了解有关 REST API 的更多细节。
如果某个 API 遵守了其中部分约束但并非全部，则可称为“类 REST”API。对于某些用例，这些约束可能弊大于利，因此您可能会遇到对该风格的局部采用。
SOAP（简单对象访问协议）高度依赖 XML。要使用它，必须严格遵守关于消息结构、编码规则以及请求和响应处理的规范。
尽管非常精确且功能强大，但受制于其标记语言，SOAP API 可能更难上手。请求和响应可能变得相当冗长且复杂，若需手动输入命令，操作起来会相当繁琐。
不过，这种风格的优势在于内置了错误处理机制。如果请求出现问题，响应中将包含大量有价值的信息，有助于你查找并纠正错误。
这种风格用于客户端应用程序通过 HTTP 查询数据库。但与向不同端点发送多个 HTTP 请求不同，您只需发送一个 POST 请求的“查询”即可满足所有需求。本质上，客户端只需描述一次需求，API 就会尽力检索该数据。
在 GraphLQ 架构下运行的服务器，针对可请求的数据预先定义了模型（或模式）。因此，当您发起请求时，该模式将作为指导方针，明确您可请求的内容、信息应如何组织，以及如何与服务器交互。
该系统的优势在于用户能清晰了解可获取的内容，因此极少出现获取错误数据或遭遇错误的情况。其核心原则是将客户端置于首位，为其提供最佳体验。
与 GraphLQ 类似，Falcor API 会创建一个虚拟 JSON 文件，作为客户端请求后将接收的数据容器。随着客户端需求的新数据不断增加，该虚拟文件可以被扩展。虽然这增加了便利性，但随着时间的推移，文件可能会变得相当庞大。
幸运的是，您无需在每次请求时都获取整个 JSON 文件。相反，您可以随时指定所需的具体部分，并在响应中获取这些内容。之所以能实现这一点，是因为该 JSON 文件发布在某个 URL 下，并链接到后端的不同资源。本质上，您可以像浏览文件一样在虚拟文件中定位所需数据。
客户端与服务器之间的这一虚拟层，在保持双方架构完全独立的同时，有效实现了两者的连接。
当您无需顾虑太多限制时，设计 API 时 gRPC 应当是您的首选方案之一。它不依赖特定语言和平台，并且由于使用 Protocol Buffers（protobufs）将数据序列化为二进制流，因此速度相当快。随后，这些数据通过 HTTP/2 进行传输。
gRPC 非常适合分布式系统。该框架最关键的特性在于其过程（procedures）。您可以在本地机器和远程设备上运行这些过程。无论哪种情况，调用过程都快速且直观。
API 日益流行的一大原因是，微服务相较于传统的单一服务软件模型具有显著优势。通过这种方式，每个功能/微服务均可独立设计、开发和更新，而不会影响其他组件。从这个意义上讲，gRPC 是将所有组件紧密连接在一起的绝佳解决方案。
此外，由于可以远程启动过程，它也非常适合将移动设备连接到后端服务。
虽然本文为您概述了最常见的 API 架构风格，但这还不足以确保您选对了。对我们团队而言，拥有尽可能多的实际案例经验至关重要。
这里所说的经验，既包括作为用户的体验，也包括作为开发者的实践。毕竟，也许有一种风格你更熟悉，因此构建起来会更容易，但你必须设身处地站在最终用户的角度，看看这对他们来说效果如何。
API 风格并非开发中途随意选择或后期随时切换的事物。它是一套决定 API 形态的规则手册。因此，这是一个重大的决策。
你可以采取的第一步是阅读市场上现有 API 的文档，最好能亲自测试一番。若曾有构建 API 的经验，则会是巨大的优势。
如果您想了解我们是如何将 WebScrapingAPI 打造成如今这般强大的网络爬虫工具的，不妨查阅我们的文档。要知道，其当前的许多功能在发布之初也并不存在。诸如爬取 REST API 端点或文件等选项，都是应用户要求添加的。因此请记住：架构风格旨在为您提供方向，但将 API 打造成用户喜爱的工具，才是您的职责所在。
罗伯特·蒙塞阿努（Robert Munceanu）是 WebScrapingAPI 的全栈开发工程师，他在产品各领域均有贡献，并协助构建了支持该平台的可靠工具和功能。
