接口设计之道： RPC 与 RESTful 的抉择与融合

在现代软件开发中， API 接口设计是系统架构的基石。通过近期关于“统一使用 POST”、“gRPC”、“RESTful”等话题的深入探讨与沟通，我们厘清了不同设计范式的本质、优劣及其适用场景，形成了更清晰的架 构认知。

一、 核心理念：两种设计范式

最根本的区分在于

设计理念

：

  

RPC (Remote Procedure Call)

： 

以

“

动作

”

或

“

方法

”

为核心

。其思维模式是“我要执行一个叫createOrder 或 dischargePatient 的操作”。它将远程服务调用模拟为本地函数调用，关注“

做什么

”。典型的特征是“动词+主语”的接口命名（如  /api/createUser ）和统一使用  POST 方法 传输包含方法名和参数的请求体（如 JSON-RPC）。 RPC 的优势在于

直观、直接、沟通成本

低

，特 别适合封装复杂的、非标准化的业务流程。

  

RESTful (Representational State Transfer)

： 

以

“

资源

”

为核心

。其思维模式是“我要操作一个 User 或  Order 资源”。它利用 HTTP 协议的语义，通过标准的  GET （获取）、 POST （创建）、 PUT / PATCH （更新）、 DELETE （删除）方法对资源进行操作，关注“

操作哪个东西

”。 URI 代表资源（如 /users/123 ），操作的语义由 HTTP 方法表达。 RESTful 的优势在于

统一接口、可

 缓存性

（ GET 请求可被浏览器、 CDN 缓存）、

无状态性

和与 Web 生态的天然契合。

二、 统一

POST

：利弊权衡

为减少沟通成本而“统一使用 POST”是一种常见实践。其

优点

显著：简化开发规范，能轻松处理复杂参  数（避免 URL 长度限制），防火墙兼容性好。然而，其

缺点

更为深远：它

完全违背了

HTTP

 

方法的语

  

义

，导致操作意图模糊（是读取还是写入？）， 

彻底丧失了

 

GET  

请求的可缓存能力

，严重影响系统性 能和可扩展性，并且使客户端难以利用方法的幂等性（ PUT / DELETE ）进行安全重试。

三、 演进与优化：务实的中间路线

认识到“统一 POST”的弊端后，公司采取了更优策略：采用“

动词

+

主语

”命名，并区分“

静态资源用

GET

，

 

动态资源用

POST

”。这是一个

务实的进步

：

  

优点

： “动词+主语”在应用层恢复了操作语义；将读取操作（静态资源）回归 GET  ，

关

键性地恢复

 了缓存能力

 

，实现了有效的读写分离。

  

局限：  POST 仍承担了创建、更新、删除等多种职责，失去了  PUT / DELETE  的幂等性保证，且 “动词”命名本质上仍是 RPC 风格，偏离了 RESTful 的资源导向思想。

四、 技术本质：

 

RPC over

HTTP

 

的合理性

技术经理提出的“我们用的是 RPC over HTTP ， RESTful 只是参考”这一说法，

极具合理性

。它准确地描  述了当前架构的本质——利用 HTTP 作为传输载体，进行远程过程调用。这种模式在内部系统、微服务 通信或复杂业务场景中非常普遍且高效。它不追求 RESTful 的教条，而是优先保障

业务表达

的直接性和

 

开发效率

。对于像“处理出院”这类复杂业务操作，强行映射到  POST / PUT / DELETE 会非常别扭（是  POST /discharge ？还是  PATCH /patient {"status": "discharged"} ？），而直接定义一个  dischargePatient 的 RPC 方法则清晰明了。

五、

gRPC

：

 

RPC

理念的现代化演进