大家好，我是比特桃。目前我们的生活紧紧地被大量互联网服务所包围，互联网上每天都有数百亿次API调用。API 是两个设备相互通讯的一种方式，人们在手机上每次指尖的悦动，背后都是 API 接口的调用。

本文将列举常见的一些 API 接口，并阐述它们之间的优缺点及关系。

一、API 类型

常用的 API 类型有很多，但本文聚焦于 HTTP 之上的 API 接口（通用性）。像 TCP 传输层之上的其他应用层协议，如 MQTT 之类的，不在本文的讨论范围。

1.1 SOAP

SOAP 协议基于XML，应用于安全性和可靠性至关重要的金融服务和支付网关，比较适合对数据安全等级较高的场景。

1.2 RESTful

基于JSON的轻量级 web 服务，也是目前应用最广泛的 API 协议。

1.3 gRPC

高性能微服务通讯协议，它是微服务架构最爱。

1.4 GraphQL

一种客户端可动态定制化的 API 协议，它不仅仅是一种API通讯方式，还是一种查询语言。

1.5 WebSocket

WebSocket 是实时通讯的常用手段，基于HTTP协议。关于实时、双向和持久连接的。如果只需要服务器实时推送，也可以尝试同样基于 HTTP 的 SSE（Server-sent events）。

1.6 Webhook

自定义远程回调函数，通常用于自动化处理。我们在使用自动化部署 Jenkins 的时候有用到过：十分钟搞定Jenkins+Gitlab+Docker前后端部署

下面我们将详细介绍三个最常用的 API 接口：RESTful、GraphQL、gRPC。

二、RESTful 详解

RESTful API在移动互联网时代中有着广泛的应用，因为它足够的轻量（基于JSON），非常灵活。

REST API规定了许多标准，比如：统一接口、通讯方式、无状态、可缓存等。遵循 REST API 标准的 API 称为 Restful API，为了保障 API 接口的可维护性，一般开头会有 v1/v2/v3 这种类似的版本号。

需要注意的是，URL的资源是按名词来命名，而不是动词，比如你可以命名：

https://example.com/api/v3/products

而不是：

https://example.com/api/v3/getALLproducts

这也是很多不规范的“RESTful API”最容易犯错的地方，REST API 规定，动作是用 URI 进行的。

HTTP请求头的类型所对应的动作如下表所示，也是我们常说的：CRUD 增删改查：

HTTP 常见的返回码对应的含义如下表所示：

此外，还要注意 API 接口的幂等性问题。只有在进行 POST 创建操作的时候是不具备幂等性的，我们要注意客户端的多次请求，所导致的数据重复问题。

三、GraphQL 详解

Meta 公司开发的接口协议，目前 Github、Shopify、Ins 等均在使用。最大的特点就是灵活性和高效率，对于其产品有复杂数据要求的，提供了很好的选择方案。GraphQL 和我们刚刚说的 RESTful API 有很多相似之处，比如它们都是基于http、均通过 URL 进行统一资源定位、数据传输采用 JSON 格式。但GraphQL 独有的优势在于，客户端可定制化的选择接口返回的内容，这极大的提高了程序的动态扩展能力。

如果我们一个动作需要多个数据的组合，那在 RESTful API 中，可能面临多个请求。但在GraphQL中可以在请求头中进行数据定制，GraphQL 将组织好数据进行返回。

但它也有一定缺陷，一方面是不易进行缓存。GraphQL具有单一入口点，并且默认使用 HTTP POST，会妨碍 HTTP 缓存的充分利用。另一方面是因为可以随意自定义数据，这会可能会产生一些危险。

四、gRPC 详解

RPC 大家应该不算陌生，Remote Procedure Call 远程过程调用。也就是说两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的方法。由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。

gRPC 是Google 2016年创建的开源远程过程调用框架，它重写了他们过年的内部RPC基础设施并开源出来。gRPC 是 RPC 的一种流行实现，许多组织已采用 gPRC 作为首选的 RPC 实现方案。还有Openfeign、Dubbo这种框架也可以作为 RPC 的实现方案。
gRPC生态系统的核心是使用 Protocal Buffers （协议缓冲区）作为其数据交换格式。它是一种和语言及平台无关的机制，用于编码结构化数据。

gRPC 使用 Protocal Buffers 进行编码并通过线路发送数据。虽然gRPC也可以通过 JSON，但Protocal Buffers 提供了多种优势，使其成为 gRPC 的首选编码格式。通过定义通讯协议 proto 文件，来让微服务之间进行通讯，写好 proto 后可以通过工具自动生成不同语言的实现：

之所以 gRPC 具有超高的性能，Protocol Buffers 的通讯方案是重点。它是一种非常高效的二进制编码格式，比 JSON 快得多。

另一个高效率的原因是，gRPC 构建在HTTP/2 之上，以提供大规模的高性能基础。gRPC使用 HTTP/2 Stream，它允许通过单个长期的TCP连接发送多个消息流。HTTP/2 的好处有：多路复用、流优先、二进制协议、服务推送。当然，Openfeign也可以通过配置使用 HTTP/2。

gRPC由于二进制编码和网络优化，效率很高，比JSON快5倍。下图为 gRPC 通讯的过程：

说了这么多 gRPC 的好处，那为什么服务端在与客户端通讯的时候没采用 gRPC 协议呢？这是因为gRPC依赖于对HTTP/2原生较低级别的访问，目前没有浏览器支持 gRPC 客户端所需的网络请求控制级别。
不过目前可以在代理的帮助下从浏览器进行 gRPC 调用。这项技术被称为 gRPC-Web。但是该功能集并不能与 gRPC 完全兼容。但在移动端其实有在使用，在电量和带宽受限的环境中非常有意义。

五、API 优化

• 使用缓存，可以采用类似 Redis 这种工具，将数据进行缓存以提供高效率的通讯。
• 连接池，使用多路复用技术，用来减少对数据库的访问。
• 避免 N+1 查询，当一个接口需要采用多个 SQL 语句的时候，尝试组合使用一个。
• 使用分页，减少数据通讯的代价，换取更快的加载速度。
• 采用 JSON，轻量级的 JSON 通讯可以在服务端与客户端中保持平衡。
• 压缩，可以用 Brotli 算法对数据进行压缩，许多CDN（内容分发网络）也可以支持压缩。
• 异步日志记录，当高并发的时候，这类工作可以分发到别的微服务中进行。

六、总结

本文我们了解了基于 HTTP 应用层协议之上的，常用六种 API 接口：RESTful、GraphQL、gRPC、WebSocket、Webhook。每一个都具有自己鲜明的特色及应用场景，我们应该根据产品以及团队的具体情况才选择使用。没有最好的 API 接口，只有最适合的场景及应用。