接口设计之道： 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 理念的现代化演进

gRPC 并非使用传统意义上的  POST 。它是一个基于 HTTP/2 的现代 RPC 框架。开发者定义服务和方法 （如  rpc GetUser(...) ），框架在底层将所有调用封装为 HTTP/2 的  POST 请求进行传输。但这对  开发者是透明的。 gRPC 的核心是方法调用和高效的 Protobuf 序列化，而非 HTTP 方法语义，它是

RPC 理念的高性能实现。

六、 结论：设计是权衡的艺术

最终，选择 RPC 还是 RESTful 并非简单的对错问题，而是一场权衡：

  优先业务效率与复杂性： 若系统涉及大量复杂、特定的业务流程，团队追求开发速度和沟通清 晰， RPC 风格（或 RPC over HTTP）是务实之选。

  优先标准化与生态集成： 若 API需对外公开，希望被广泛消费，或极度依赖缓存提升性能，  遵循 RESTful 原则（或借鉴其思想）更有价值。

当前的策略——承认“RPC over HTTP”的本质，借鉴 RESTful 的优点（如用  GET 实现缓存） ——是 一种在理想与现实之间取得良好平衡的成熟架构实践。它既避免了“伪 REST”的混乱，又充分利用了现有 技术的优势，是应对复杂业务挑战的明智决策。