API 架构学习

MQTT架构 

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输协议），是一种基于发布/订阅（publish/subscribe）模式的“轻量级”通讯协议，该协议构建于TCP/IP协议上，由IBM在1999年发布。

MQTT最大优点在于，用极少的代码和有限的带宽，为连接远程设备提供实时可靠的消息服务。

作为一种低开销、低带宽占用的即时通讯协议，使其在物联网、小型设备、移动应用等方面有较广泛的应用。

SOAP 

SOAP (Simple Object Access Protocol) 是一种基于 XML 的协议，用于在 Web 上进行消息传递。它允许应用程序在分布式环境中进行交互，并支持不同操作系统和编程语言之间的通信。多应用于HTTP/SMTP。

GraphQL API

GraphQL  （Graph Query Language）是一种开源的、行业标准的 API 查询语言。 是一种针对 Graph（图状数据）进行查询特别有优势，  与围绕资源操作设计的 REST 风格 API 不同，GraphQL API 支持更广泛的用例，并专注于数据类型、模式和查询。(Facebook发明？)

Webhook

Webhook 是一个 API 概念，是微服务 API 的使用范式之一，也被成为反向 API，即前端不主动发送请求，完全由后端推送；举个常用例子，比如你的好友发了一条朋友圈，后端将这条消息推送给所有其他好友的客户端，就是 Webhook 的典型场景。

REST API

REST API 是一种符合 REST（Representational State Transfer） 的设计原则或“具象状态传输” 或翻译为“表现层状态转化 ” 架构风格的 API。 出于这一原因，REST API 有时也称为 RESTful API。

它们要符合以下六种 REST 设计原则 - 也称为架构约束：

1统一接口。 无论请求来自何处，对同一资源发出的所有 API 请求都应该看起来相同。 REST API 应确保同一条数据（例如用户的姓名或电子邮件地址）仅属于一个统一资源标识符 (URI)。 资源不应过大，但应包含客户可能需要的每一条信息。

2客户端/服务器解耦。 在 REST API 设计中，客户端和服务器的应用程序必须彼此完全独立。 客户端应用程序应该知道的唯一信息是所请求资源的 URI；它不能以任何其他方式与服务器应用程序交互。 同样，除了通过 HTTP 将客户端应用程序传递到所请求的数据外，服务器应用程序不应修改客户端应用程序。

3无状态。 REST API 是无状态的，这意味着每个请求都需要包含处理它所需的全部信息。 换句话说，REST API 不需要任何服务器端会话。 不允许服务器应用程序存储与客户端请求相关的任何数据。

4可缓存性。 如果可能，资源应该可以在客户端或服务器端缓存。 服务器响应还需要包含有关是否允许对交付的资源进行缓存的信息。 目标是提高客户端的性能，同时增强服务器端的可扩展性。

5分层系统架构。 在 REST API 中，调用和响应都会经过多个不同的层。 根据经验，不要假设客户端和服务器应用程序直接连接到彼此。 通信环路中可能包含多个不同的中介服务器。 需要设计 REST API，让客户端和服务器都无法判断它是与最终应用程序还是中介服务器进行通信。

6按需编码（可选）。 REST API 通常发送静态资源，但在某些情况下，响应也可以包含可执行代码（例如 Java 小程序）。 在这些情况下，代码只应按需运行。

WebSocket

WebSockets 允许用户和服务商之间建立一个持久的双向通信来满足信息交互。

适用于需要大量实时稳定的应用场景

有引用red/ibm/tomcat等开源网站解释及介绍