5 种最常见的 API 风格
在用例方面，值得一提的是，API 可以是公开的、向合作伙伴开放的，也可以是完全内部的。这第一个区别为许多需要开发的特性和功能设定了标准：如何存储和共享数据、如何处理凭证、API 需要多少流量等。
正如你所看到的，以下建筑风格可用于这三种情况中的任何一种，但有些组合比其他组合更有意义。
1.REST API
这是目前最常见的应用程序接口，也是我们用来构建WebScrapingAPI 的风格。其缩写是 "REPresentational State Transfer"（呈现状态传输）的缩写，这种风格规定，如果您作为客户端提出请求，应用程序接口将发回您所请求的资源的状态表示。
RESTful API 在很大程度上基于 HTTP 基础架构。由于网络一般主要使用 HTTP，REST API 具有易于理解、集成和使用的优势。
这种风格也是由 API 必须遵守的一系列约束条件定义的。虽然一开始听起来很麻烦，但这些约束可以确保应用程序接口以可预测和有益的方式运行。一共有六个，它们是这样的
- 统一界面
- 无国籍
- 可缓存
- 客户端-服务器
- 分层系统
- 按需编码
我们已经在 Medium 上发表了一整篇关于这些限制的文章，请查看这篇文章，了解有关 REST API 的更多细节。
如果一个应用程序接口遵守了其中的一些限制，但没有遵守所有限制，那么它们就可以被称为类 REST。对于某些用例，这些约束带来的麻烦可能会多于好处，这就是为什么你可能会遇到部分采用这种风格的情况。
2.SOAP 应用程序接口
SOAP 或简单对象访问协议（Simple Object Access Protocol）在很大程度上依赖于 XML。要使用它，就必须遵守有关信息结构、编码规则以及处理请求和响应的严格标准。
SOAP 应用程序接口虽然非常精确和广泛，但由于其标记语言的原因，使用起来可能比较困难。请求和响应可能会变得相当冗长和复杂，如果手动键入命令，就会很麻烦。
从好的方面看，这种方式具有内置错误处理功能的优势。如果您在请求中遇到问题，响应将包含大量有价值的信息，可以帮助您找到并纠正错误。
3.GraphLQ 应用程序接口
这种方式用于通过 HTTP 从客户端应用程序查询数据库。不过，您可以只发布一个 "查询"，就能获得所需的全部信息，而不用向不同的端点发送多个 HTTP 请求。从本质上讲，客户端只需描述一次所需的内容，应用程序接口就会尽力检索这些数据。
在 GraphLQ 架构下运行的服务器会为可请求的数据预制一个模型（或模式）。因此，当您发出请求时，该模式将作为您可以请求的内容、信息的结构以及如何与服务器交互的指南。
这种系统的优势在于用户可以清楚地了解他们可以获得什么，因此检索到错误数据或遇到错误的可能性很小。其基本原则是将客户放在首位，为他们提供最佳体验。
4.Falcor API
与 GraphLQ 类似，Falcor API 也会创建一个虚拟 JSON 文件，作为客户端请求后接收数据的容器。该虚拟文件可根据客户需要的每项新数据进行扩展。这虽然增加了便利性，但随着时间的推移，文件可能会变得很大。
幸运的是，您不必在每次请求时都检索整个 JSON 文件。相反，您可以随时指定您需要的部分，并在响应中获取这些部分。这是因为 JSON 文件发布在一个 URL 下，并链接到后台的不同资源。从本质上讲，您可以在虚拟文件中浏览您想要的数据。
客户端和服务器之间的虚拟层有助于将两者连接起来，同时保持两者的架构完全独立。
5. gRPC
在设计应用程序接口时，如果需要考虑的限制较少，gRPC 应该是首选之一。它与语言无关、与平台无关，而且由于使用协议缓冲区（protobufs）将数据序列化为二进制流，因此速度相当快。然后通过 HTTP/2 传输数据。
gRPC 非常适合分布式系统。这种风格最重要的一点是程序。你可以在本地机器和远程设备上运行它们。在这两种情况下，调用存储过程都非常快速和简单。
应用程序接口变得流行的原因之一是，与传统的单一服务软件模式相比，独立的微服务更具优势。这样，每个功能/微服务都可以单独设计、开发和更新，而不会影响其他组件。从这个意义上说，gRPC 是将这一切联系在一起的绝佳解决方案。
此外，由于可以远程启动程序，它也非常适合将移动设备连接到后台服务。
如何选择正确的应用程序接口
本文为您概述了最常见的 API 架构风格，但这还不足以确保您选择正确的架构风格。对我们团队来说，尽可能多地使用第一手实际经验至关重要。
我所说的经验，既指作为用户的经验，也指作为开发人员的经验。毕竟，也许有一种风格是你比较熟悉的，因此构建起来会比较容易，但你必须设身处地地为最终用户着想，看看对他们来说效果如何。
风格不是你可以在开发过程中随便选择的，也不是你可以在以后随便切换的。它是一本规则手册，决定了 API 如何成型。因此，这是一个重大的决定。
您可以采取的第一步是阅读市场上已有的应用程序接口的文档，最好对其进行测试。如果以前有过构建应用程序接口的经验，那将会是一大优势。
如果您想了解我们是如何将 WebScrapingAPI 塑造成现在这样一个强大的网络抓取工具的，不妨 查看我们的文档。目前的功能也并非都是发布时就有的。我们应用户的要求添加了 REST API 端点或文件刮擦等选项，因此请记住：架构风格旨在为你指明方向，但如何将 API 塑造成人们喜爱的产品则是你的工作。
