API有很多分类。但是当涉及到网络通信时，我们可以确定两种重要的API类型Web Service APIs（例如SOAP，JSON-RPC，XML-RPC，REST）和Websocket API。但是，这些到底是什么意思？让我们深入了解Web通信协议的世界，并在最后讨论如何选择最佳的API机制。
HTTP
HTTP是互联网的基础通信协议。HTTP在客户端-服务器计算模型中充当请求-响应协议。 HTTP / 1.1是现代Web浏览器和服务器中使用的最常见的HTTP版本。与HTTP的早期版本相比，此版本可以实现关键的性能优化和功能增强，例如持久性和流水线连接，分块传输，请求/响应主体中的新标头字段等。其中，以下两个标头非常值得注意，因为HTTP的大多数现代改进都依赖于这两个标头。
-
Keep-Alive标头，用于为主机之间的长期通信设置策略（超时时间和每个连接要处理的最大请求数） -
Upgrade标头，用于将连接切换到增强的协议模式，例如HTTP / 2.0（h2，h2c）或Websockets（websocket）
REST
到目前为止，REST（REpresentational State Transfer）的体系结构样式是构造用于请求的Web API的最标准化的方式。REST纯粹是一种基于多种原则的建筑风格。遵循REST原理的API称为RESTful API。REST API使用请求/响应模型，其中来自服务器的每个消息都是对来自客户端的消息的响应。通常，RESTful API使用HTTP作为其传输协议。在这种情况下，查找 应使用GET请求。PUT，POST和DELETE的要求应当用于修改，插入，和删除分别（避免GET用于更新信息的请求）。
HTTP轮询
在HTTP轮询中，客户端通过遵循以下机制之一来轮询请求新信息的服务器。如今，大多数应用程序都使用轮询，并且大多数情况下轮询是通过RESTful实践进行的。实际上，很少使用HTTP短轮询，并且始终选择HTTP长轮询或定期轮询。
- HTTP短轮询：更简单的方法。许多请求在到达服务器时都会被处理，从而产生大量流量（使用资源，但是一旦将响应发送回去就释放了它们）。由于每个连接仅在短时间内打开，因此可以对许多连接进行时分复用。
00:00:00 C-> Is the cake ready?
00:00:01 S-> No, wait.
00:00:01 C-> Is the cake ready?
00:00:02 S-> No, wait.
00:00:02 C-> Is the cake ready?
00:00:03 S-> Yeah. Have some lad.
00:00:03 C-> Is the other cake ready?
- HTTP长轮询：一个请求发送到服务器，客户端等待响应。服务器将请求保持打开状态，直到有新数据可用（未解决且资源被阻塞）为止。服务器事件发生时，将立即收到通知。更复杂，使用了更多服务器资源。
12:00 00:00:00 C-> Is the cake ready?
12:00 00:00:03 S-> Yeah. Have some lad.
12:00 00:00:03 C-> Is the other cake ready?
- HTTP定期轮询：两个请求之间存在预定义的时间间隔。这是轮询的改进/管理版本。您可以通过增加两个请求之间的时间间隔来减少服务器消耗。但是，如果需要在服务器事件发生时立即得到通知，则这不是一个好的选择。
00:00:00 C-> Is the cake ready?
00:00:01 S-> No, wait.
00:00:03 C-> Is the cake ready?
00:00:04 S-> Yeah. Have some lad.
00:00:06 C-> Is the other cake ready?
HTTP流
HTTP流传输—提供长期连接，可进行即时和连续的数据推送
客户端发出一个HTTP请求，服务器发送一个不确定长度的响应（就像无限轮询一样）。HTTP流是高性能，易于使用的，并且可以替代WebSockets。
- 缺点：中介可以中断连接（例如，超时，中介以循环方式处理其他请求）。在这种情况下，它不能保证完整的实时性。
00:00:00 CLIENT-> I need cakes
00:00:01 SERVER-> Wait for a moment.
00:00:01 SERVER-> Cake-1 is in process.
00:00:02 SERVER-> Have cake-1.
00:00:02 SERVER-> Wait for cake-2.
00:00:03 SERVER-> Cake-2 is in process.
00:00:03 SERVER-> You must be enjoying cake-1.
00:00:04 SERVER-> Have cake-2.
00:00:04 SERVER-> Wait for cake-3.
00:00:05 CLIENT-> Enough, I'm full.
SSE（服务器发送的事件/ EventSource）
- SSE连接只能将数据推送到浏览器。（仅从服务器到浏览器进行通信，浏览器只能预订由服务器发起的数据更新，而不能向服务器发送任何数据）
00:00:00 CLIENT-> I need cakes
00:00:02 SERVER-> Have cake-1.
00:00:04 SERVER-> Have cake-2.
00:00:05 CLIENT-> Enough, I'm full.
- 示例应用程序：Twitter更新，股票报价，板球得分，浏览器通知
- 问题1：某些浏览器不支持SSE。
- 问题2：通过HTTP / 1.1的最大打开连接数限制为6或8（基于浏览器版本）。如果使用HTTP / 2，将不会有问题，因为一个单一的TCP连接足以满足所有请求（由于HTTP / 2中的多路支持）。
HTTP / 2服务器推送
- 服务器预先主动将资源（css，js，媒体）推送到客户端缓存的机制
- 示例应用程序：社交媒体供稿，单页应用程序
HTTP / 2是基于复用的流的有效传输层 -根据IETF，“流”是一个HTTP / 2连接内的客户机和服务器之间交换的帧的独立的，双向序列。它的主要特征之一是单个HTTP / 2连接可以包含多个并发打开的流，其中任一端点都可以从多个流中插入帧。
- 缺点1：中介机构（代理，路由器，主机）可以选择不按照原始服务器的意图将信息正确地推送到客户端。
- 缺点2：连接不会无限期保持打开状态。即使发生内容推送过程，连接也可以随时关闭。一旦关闭并再次打开，该连接就无法从其离开的地方继续。
- 缺点3：某些浏览器/中介不支持服务器推送。
WebSocket
WebSocket允许服务器和客户端在任何时间推送消息，而与先前的请求没有任何关系。使用WebSockets的一个显着优势是，几乎每个浏览器都支持WebSockets。
WebSocket解决了HTTP的一些问题：
- 双向协议-客户端/服务器都可以向另一方发送消息（在HTTP中，请求始终由客户端发起，响应由服务器处理-使HTTP成为单向协议）
- 全双工通信-客户端和服务器可以同时独立地相互通信。
- 单个TCP连接-在开始升级HTTP连接后，客户端和服务器在WebSocket连接的整个生命周期中都通过同一TCP连接进行通信。
00:00:00 CLIENT-> I need cakes
00:00:01 SERVER-> Wait for a moment.
00:00:01 CLIENT-> Okay, cool.
00:00:02 SERVER-> Have cake-1.
00:00:02 SERVER-> Wait for cake-2.
00:00:03 CLIENT-> What is this flavor?
00:00:03 SERVER-> Don't you like it?
00:00:04 SERVER-> Have cake-2.
00:00:04 CLIENT-> I like it.
00:00:05 CLIENT-> But this is enough.
示例应用程序：IM / Chat应用程序，游戏，管理前端
尽管据说每个浏览器都支持WebSockets，但中介程序中也可能有例外：
- 中介程序中的意外行为：如果您的WebSocket连接通过代理/防火墙，则您可能已经注意到此类连接始终失败。始终使用安全WebSocket（WSS）来大大减少此类故障。
- 不支持WebSocket的中介：如果由于某种原因WebSocket协议不可用，请确保您的连接自动回退到合适的长轮询选项。
REST与Websockets —性能测试
如果对REST和Websockets进行性能测试，则可能会发现存在高负载时Websockets的性能更好。这并不一定意味着REST效率低下。我个人的看法是，将REST与Websockets进行比较就像将苹果与橙子进行比较。这两个功能解决了两个不同的问题，无法与像这样的简单性能测试进行比较：
在第一个图中，REST开销增加了许多消息，因为需要启动和终止许多TCP连接，并且需要发送和接收许多HTTP标头。在第二张图中，REST端点处理请求/响应的增量成本最小，并且大部分时间都花在了连接启动/终止和遵守HTTP语义上。
但是，您现在应该了解，WebSockets是以近乎实时的方式处理长期存在的双向数据流的绝佳选择，而REST非常适合偶尔进行的通信。使用WebSockets本身占用资源比较多，因此对于偶尔的连接来说是过大的选择。
Webhooks（用于服务器之间的通信）
如果要在数据更改时从API获取数据，则必须首先考虑使用轮询。但是，当涉及服务器之间的通信时，低效率的轮询使我们付出了很多代价（平均而言，浪费了98.5％的轮询）。
Webhooks —在没有长期轮询连接的服务器之间发送数据的简单方法
Webhooks是此问题的救星。在此请记住，通信通常发生在服务器之间。首先，发送方节点预先在接收方节点中注册一个回调URL。当发送方发生事件时，Webhook会被触发，并使用在每个接收方中注册的回调URL，将带有新数据的事件对象作为HTTP POST请求发送到接收方节点。
很酷的事情是，可以通过webhooks大大减少发送方和接收方节点的服务器负载。它可以确保更好的用户体验，同时开发人员可以将服务端点用于有意义的事情，而不会浪费轮询。
Webhooks通常用于在事件发生时在服务器之间发送通知和状态更改。例如，当用户通过单击电子邮件中的按钮取消订阅时，它到达服务器，并且发生用户取消订阅事件，此事件触发相应的Webhooks，并且他们通知所有服务器/服务该用户现在已经从其订阅服务器中取消订阅。服务
- 示例应用程序：新用户注册或当前用户更新现有配置文件设置时的通知
- 缺点：开发人员发现难以设置webhooks和扩展HTTP服务。
下一个API使用什么？
使用哪种技术取决于在您的应用程序上下文中什么才更有意义。当然，您可以使用一些技巧来模拟一种技术与另一种技术的行为，但是通常更可取的是使用一种更适合您的通讯模型的技术（当被本书使用时）。
HTTP / 1.1与HTTP / 2：这是传输协议。HTTP / 2中的多路复用功能很棒，但目前尚不支持。在这种情况下，请确保从HTTP / 2和HTTP / 1.1回退不会在您的应用程序中造成任何混乱。对于传输数据，HTTP / 1.1仍然是一个不错的选择。
RESTful API：到目前为止，RESTful API适用于Web应用程序。但是，正在探讨探索更好的方法。我喜欢这个想法，事实上，JSON对开发人员友好，您可以用它做奇迹。但您知道，这些正在发展中。
JSON与XML：使用JSON。这是趋势，因此也很方便处理。
HTTP轮询：虽然很老，但仍然是处理API的绝佳选择。如果您的数据经常更改或实时更改，请不要使用“短轮询”，而要使用WebSockets（实时性更好的技术）。始终适当地使用长周期轮询（使用REST原则）。
HTTP流：这对于新闻/社交媒体提要，股票/记分板，推文等应用程序非常有用。但是实际上，人们使用WebSocket的方式比HTTP流多。
HTTP / 2服务器推送非常适合以更托管的方式向客户端发送资源。但是，所有中介和浏览器均不支持此功能。确保妥善处理此类后备问题。
服务器发送的事件是一项相当新的技术，尚不受所有主流浏览器的支持，因此它并不是严肃的企业级Web应用程序的一种选择（是的，我同意您可以欺骗该技术以使其工作） 。
WebSockets提供了更丰富的协议来执行双向全双工通信。对于游戏，消息传递应用程序，协作工具，交互式体验（包括微交互）以及需要双向实时更新的情况，拥有双向通道更具吸引力。
Webhooks与上述所有技术均不同，因为它解决了一个非常具体的问题。如果您的服务器需要频繁和/或双向通信，请使用WebSockets。如果您的服务器偶尔进行通信，请使用REST调用。如果您的服务器需要在事件触发器上进行单向通信，则请进行Webhooks。不要使用轮询来检查数据或状态的更改，这是浪费。
参考
HTTP and Websockets: Understanding the capabilities of today’s web communication technologies
