接口分类
- 一、基础：OSI七层模型与TCP/IP四层模型
- 二、按通信协议分类（底层传输规则）
- 三、按业务、功能场景
- 三、按技术实现分类
- [四、按传输方式 （数据格式）](#四、按传输方式 （数据格式）)
- 五、接口核心类型对比
- 六、接口鉴权方式
- 七、接口选型
- 八、总结
一、基础：OSI七层模型与TCP/IP四层模型
1、TCP/IP 四层模型（1981 年明确）
核心设计思路：把 OSI 七层的上三层合并、下两层合并，是实际网络中广泛使用的工业标准。
| TCP/IP 四层模型 | 对应 OSI 七层模型 | 合并原因 |
|---|---|---|
| 应用层 | 应用层 + 表示层 + 会话层 | 这三层都直接面向应用程序，功能关联性强，实际使用中无需严格拆分 |
| 传输层 | 传输层 | 端到端传输是网络通信的核心，独立分层更利于可靠传输控制 |
| 网际层 | 网络层 | IP 寻址和路由是跨网通信的关键，是互联网的核心层级 |
| 网络接口层 | 数据链路层 + 物理层 | 这两层都负责底层物理传输和局域网通信，硬件和协议关联性强 |
2、OSI 七层模型（1984 年正式发布）
OSI 模型（Open Systems Interconnection Reference Model，开放式系统互联参考模型）是国际标准化组织（ISO）制定的网络通信功能分层架构标准。
核心思路：将复杂的网络通信过程拆解为 7 个独立层级，每一层专注于特定功能，层与层之间通过标准化接口交互，降低整体系统的设计和维护复杂度。
| 层级 | 核心功能 | 典型设备/协议 |
|---|---|---|
| 物理层 | 物理介质上的信号传输，定义硬件规格 | 光纤、网线、集线器、中继器 |
| 数据链路层 | 局域网内通信，MAC 地址寻址，帧封装 | 交换机 |
| 网络层 | 跨网络路由选择，IP 地址寻址 | IP（IPv4/IPv6）、路由器、三层交换机 |
| 传输层 | 端到端数据传输，端口寻址，可靠/不可靠传输 | TCP、UDP、防火墙 |
| 会话层 | 建立、管理、终止通信会话 | RPC、NetBIOS |
| 表示层 | 数据格式转换、加密解密、压缩解压 | - |
| 应用层 | 直接面向用户应用，提供网络服务接口 | HTTP、HTTPS、FTP、SMTP、DNS |
3、核心总结
- OSI 七层是 理论标准，定义了网络通信的完整功能分层；
- TCP/IP 四层是 实际应用标准，通过合并 OSI 的上三层和下两层，简化了架构，成为互联网的基础。
二、按通信协议分类（底层传输规则）
- 在软件开发中，接口是系统间通信的"桥梁"，无论是前后端交互、第三方服务集成，还是微服务架构下的内部协作，都离不开接口。
- 在 OSI 七层协议模型 中，接口相关的功能主要分布在应用层、表示层、会话层，而我们日常开发和测试中所说的API 接口，本质是基于应用层协议实现的逻辑接口。
- 应用层（第 7 层）：是与用户应用程序直接交互的层次，HTTP、HTTPS、FTP 等协议都处于这一层，我们开发测试的RESTful API、RPC 接口等，都是在应用层定义的通信规范。
- 表示层（第 6 层）、会话层（第 5 层）：会辅助接口实现数据格式转换、会话建立与管理等功能，是接口通信的支撑层。
- 通信协议是接口数据传输的"语言"，决定了数据的传输效率、实时性和可靠性，是接口选型的首要考虑因素。
| 协议类型 | 核心特性 | 适用场景 | 典型案例 |
|---|---|---|---|
| HTTP/HTTPS 接口 | 1. 基于"请求-响应"模型，短连接； 2. 支持GET/POST/PUT/DELETE等标准方法； 3. HTTPS通过SSL加密，安全性高； 4. 数据格式灵活（JSON/XML/FormData） | 1. 非实时性数据交互（如查询、提交）； 2. 跨平台/跨语言的通用场景； 3. 对外暴露的开放API（需安全性） | 1. 电商商品详情查询（/api/goods/{id}）； 2. 微信登录回调接口； 3. 天气API、短信发送API |
| WebSocket 接口 | 1. 全双工通信，长连接（一次握手后持续交互）； 2. 基于TCP，数据帧轻量（头部仅2-10字节）； 3. 支持服务器主动推送数据 | 1. 实时性要求高的场景； 2. 流式数据传输（如大模型输出）； 3. 双向交互场景 | 1. 即时聊天（企业微信客服）； 2. 讯飞星火/OpenAI的流式生成接口； 3. 股票行情实时推送、物联网设备上报 |
| TCP 接口 | 1. 基于TCP协议的自定义接口，无固定格式； 2. 长连接，可靠性高（数据不丢、不重复）； 3. 需手动定义数据包结构（如包头+包体） | 1. 高可靠性、低延迟的内部通信； 2. 硬件设备交互（嵌入式系统）； 3. 高频数据传输 | 1. 游戏客户端与服务器的实时通信； 2. 工业传感器与上位机的数据交互； 3. 微服务集群内部高性能通信 |
| UDP 接口 | 1. 基于UDP协议，无连接、不可靠（数据可能丢失）； 2. 传输速度快，无需握手； 3. 适合轻量化数据 | 1. 实时性优先、可容忍少量丢包的场景； 2. 广播/组播通信 | 1. 视频会议的音视频流传输； 2. 网络设备状态探测（如路由器Ping）； 3. 实时弹幕系统 |
三、按业务、功能场景
功能用途决定了接口的"职责"，不同功能的接口承担着数据处理、服务集成、权限控制等不同角色，需结合业务场景设计。
1. 数据交互类接口
这类接口是最基础的接口类型，负责系统内/系统间的数据读写，通常遵循"CRUD"逻辑：
- 查询接口 ：仅获取数据，不修改系统状态（对应HTTP的GET方法）。
示例：用户订单列表查询（/api/order?userId=123&page=1）、商品库存查询。
注意：查询接口需避免传入敏感参数（如密码），建议用GET而非POST（便于缓存）。 - 提交接口 ：向系统写入/修改数据（对应HTTP的POST/PUT方法）。
示例：用户注册（提交用户名/密码）、订单创建（提交商品ID/数量）、修改个人资料。
注意：提交接口需做参数校验（如手机号格式），并返回明确的错误信息（如"手机号已注册"）。 - 删除接口 ：删除系统中的数据（对应HTTP的DELETE方法）。
示例：删除用户收藏（/api/favorite/{id}）、日志清理接口。
注意：重要数据删除需加"软删除"（如标记is_delete=1），避免数据不可逆丢失。
2. 服务集成类接口
这类接口用于打通不同系统，实现功能扩展，常见两类：
- 第三方API接口 ：对接外部平台的成熟服务，减少重复开发。
示例：调用微信支付API完成支付、调用高德地图API获取地理位置、调用讯飞星火API实现文本生成。
集成技巧：需封装"接口适配器"（如统一异常处理、参数转换），避免第三方接口变更影响自身系统。 - 内部服务接口 ：微服务架构中，各服务间的通信接口（如Spring Cloud、Dubbo接口）。
示例：用户服务向订单服务提供"用户信息查询接口"、库存服务向商品服务提供"库存扣减接口"。
设计要点：需定义统一的服务契约（如用OpenAPI规范），并加熔断降级（如Sentinel），防止服务雪崩。
3. 控制类接口
这类接口不传输业务数据，而是控制系统状态或权限：
- 权限接口 ：验证用户身份或权限，控制资源访问。
示例：登录接口（验证账号密码并返回Token）、Token刷新接口、权限校验接口（判断用户是否为管理员）。
安全要点：Token需设置过期时间，敏感接口需加二次验证（如短信验证码）。 - 配置接口 ：修改系统或设备的配置参数。
示例：修改服务器超时时间、调整硬件设备（如摄像头）的分辨率、切换系统环境（测试/生产）。
注意：配置变更需加日志记录，重要配置需审批流程。
三、按技术实现分类
技术实现方式决定了接口的开发难度、兼容性和维护成本，需结合团队技术栈选择。
| 实现类型 | 核心特性 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|---|
| RESTful 接口 | 1. 基于HTTP协议，遵循"资源导向"（URL表示资源，HTTP方法表示操作）； 2. 数据格式以JSON为主； 3. 无状态（每次请求独立） | 1. 简洁易懂，开发成本低； 2. 兼容性强（支持所有语言/平台）； 3. 易于调试（Postman直接测试） | 1. 不支持实时通信； 2. 复杂查询需多接口组合（如多条件筛选） | 1. 对外提供的开放API（如微信公众号API）； 2. 中小型系统的前后端通信； 3. 简单数据交互场景 |
| GraphQL 接口 | 1. 客户端可自定义请求的字段（按需获取数据）； 2. 仅需一个端点（如/graphql）； 3. 强类型，有完善的Schema定义； 4. 核心查询/变更（Query/Mutation）基于HTTP协议，实时订阅（Subscriptions）功能可基于WebSocket实现。 |
1. 减少数据冗余（避免返回无用字段）； 2. 复杂查询只需一次请求； 3. 前端灵活控制数据 | 1. 学习成本高（需掌握GraphQL语法）； 2. 缓存不如RESTful友好 | 1. 前端需求多变的场景（如移动端、PC端需不同字段）； 2. 复杂数据查询（如关联多表查询） |
| RPC 接口 | 1. 远程过程调用（如Dubbo、gRPC），像调用本地方法一样调用远程服务； 2. 通常基于TCP协议，传输效率高； 3. 支持多种序列化方式（如Protobuf、Hessian） | 1. 传输效率高（比HTTP快）； 2. 适合内部服务间高频调用； 3. 服务治理能力强（如负载均衡、服务发现） | 1. 兼容性差（需两端用相同的RPC框架）； 2. 不适合对外暴露（浏览器无法直接调用） | 1. 微服务架构的内部服务通信（如电商的用户、订单、库存服务间）； 2. 高性能要求的场景（如金融交易） |
| 消息队列接口 | 1. 基于消息队列（如RabbitMQ、Kafka），异步通信； 2. 生产者发送消息到队列，消费者从队列获取消息； 3. 支持"发布-订阅""点对点"模式 | 1. 解耦系统（生产者无需等待消费者响应）； 2. 削峰填谷（应对高并发请求）； 3. 提高系统可用性（消息可重试） | 1. 实时性差（有消息延迟）； 2. 需处理消息重复消费问题 | 1. 异步场景（如用户注册后发送短信通知、订单创建后更新库存）； 2. 高并发场景（如秒杀活动的订单处理） |
四、按传输方式 （数据格式）
五、接口核心类型对比
六、接口鉴权方式
七、接口选型
- 优先选成熟协议：对外接口优先用HTTPS（而非HTTP），实时场景优先用WebSocket（而非轮询），减少自定义协议的开发和维护成本。
- 平衡性能与复杂度：内部服务高频调用选RPC（如Dubbo），对外暴露选RESTful；简单查询选RESTful，复杂查询选GraphQL。
- 安全性不可少：对外接口加身份验证（如API Key、OAuth2.0），敏感接口加数据加密（如HTTPS、AES），避免明文传输。
- 兼容性预留 ：接口设计需加"版本控制"（如
/api/v1/goods），后续迭代时不影响旧版本用户。
八、总结
接口分类不是孤立的，实际开发中需结合"协议特性+业务需求+技术栈"综合选型：比如"电商订单创建"用HTTPS的RESTful接口（兼顾安全和兼容性），"实时聊天"用WebSocket接口（满足双向实时交互），"微服务内部通信"用RPC接口（追求高性能）。掌握接口分类逻辑，才能设计出高效、稳定、易维护的接口系统。
大家有任何疑问或想法，欢迎在评论区留言讨论，也可以关注我，后续会分享更多实用内容。