前言

11种主流API协议

1. REST API->最经典、最通用 

• 定位： 资源导向，无状态通信。

• 原理： 基于HTTP和URL，依赖HTTP动词（GET、POST等）对资源进行操作。

• 特点： 设计简单、灵活。前后端交互的首选“万金油”。

• 适用： 绝大多数常规的Web服务、移动端接口。需注意的情况，数据量大时JSON解析会带来一定开销。

2. gRPC->高性能选手，跨语言利器

• 定位： 远程过程调用（RPC），极致性能。

• 原理： 基于HTTP/2，使用Protocol Buffers（二进制数据格式）进行数据序列化。

• 特点： 传输速度极快，支持多语言（如C++、Ruby、Java等）的自动代码生成。

• 适用： 对性能要求极高的微服务内部通信、移动端应用。需要特别注意，它没有REST那么直观。

3. GraphQL->面向数据需求，前端开发

• 定位： 数据查询语言。

• 原理： 客户端可以指定需要哪些字段，避免了REST “要么全拿，要么拿不到”的问题。

• 特点： 一次请求搞定所有数据，减少网络请求次数。能更好地解决“数据过多或过少”的问题。

• 适用： 复杂的前端数据需求场景、需要频繁迭代的前端应用。

4. WebSocket->实时通信

• 定位： 全双工通信（双向实时交互）。

• 原理： 建立长连接后，服务器可以主动向客户端推送数据。

• 特点： 克服了HTTP“请求-响应”的局限，实现真正的低延迟、实时互动。

• 适用： 聊天软件、在线游戏、股票行情实时推送等。需要注意，长连接会比较耗费服务器内存。

5. SOAP

• 定位： 基于XML的简单对象访问协议。

• 特点： 采用XML格式作为消息格式，极其规范严格。常使用HTTP或SMTP作为传输介质。

• 适用： 早期的企业级服务、银行金融系统等。

• 软肋：数据量巨大、解析慢、笨重，现在除了一些老系统维护，新开发的系统基本上都不用了。

6. Webhooks

• 定位： 事件回调机制。

• 原理： 在系统中发生特定事件时（如支付成功），系统通过HTTP回调通知第三方系统。

• 特点： 它是反向的API调用，不需要客户端一直轮询（问：完成了吗？），而是“完成了会主动告诉你”。

• 适用： 支付回调通知、GitHub的Webhook、物联网设备状态变化等。

7. SSE->服务器发送事件，简化版的WebSocket

• 定位： 单向的实时通信（仅服务器向客户端发送）。

• 原理： 通过HTTP连接，服务端通过“事件流”持续推送数据。

• 特点： 实现非常简单，兼容性好，不需要额外复杂的协议支持。

• 适用： 新闻推送、股市行情、实时更新。缺点是完全单向（客户端没法回传），且只有单向功能。

8. AMQP->高级消息队列协议，企业级通讯

• 定位： 消息中间件标准协议。

• 原理： 生产者发送消息 -> 交换机路由 -> 消息队列排队 -> 消费者接收消息。

• 特点： 可靠性极高，支持消息持久化和灵活的复杂路由。

• 适用： 大型企业系统、复杂的微服务解耦。

• 代价： 成本高，复杂性大，虽然稳定但比轻量级协议慢。

9. MQTT->物联网“顶流”，轻量级王者

• 定位： 专门为物联网（IoT）设计的轻量级消息协议。

• 原理： 基于发布/订阅模式，数据包极小。

• 特点： 针对低带宽、高延迟、不稳定的网络环境进行了专门优化。

• 适用： 智能家居、传感器数据传输、低功耗设备。

• 权衡： 为了轻量级，牺牲了部分安全性和可扩展性。

10. EDA->事件驱动架构

• 定位： 一种系统架构设计方式，而非单纯的传输协议。

• 原理： 系统由“事件”驱动。产生者发布事件，消费者根据事件做出反应，彻底解耦。

• 特点： 核心在于“响应性”和“可伸缩性”。异步处理，系统吞吐量极大。

• 适用： 复杂的业务系统、灵活多变的现代化电商架构。但这也意味着调试和追踪难度加大。

11. EDI->电子数据交换

• 定位： 企业与企业之间的数据交换标准。

• 原理： 使用标准化、结构化的电子文件（如采购订单、发票）在买卖双方系统间无纸化传输。

• 特点： 企业内部与外部供应商、客户间的数据交互，无需人工干预。

• 适用： 传统制造业、供应链、物流、大型零售商。

• 门槛： 硬件、专线、标准制定初期成本非常高，建设周期长。

小结

以上是对11种主流API协议的定位、用途和优劣势汇总，希望对您有所收获，如有不到之处,请多多包涵。

阅读原文：点击这里​