一句话定义：REST（Representational State Transfer，表述性状态转移）和 RPC（Remote Procedure Call，远程过程调用）是设计网络接口的两种基本思路：前者把系统看成一堆“资源”，用少数几个标准动词去操作；后者把系统看成一堆“函数”，直接按名字调用。
打个比方。REST 像图书馆：每本书是一个资源，有唯一编号（URL），你想看就 GET，想登记新书就 POST，想替换就 PUT，想下架就 DELETE——动词只有那么几个，谁来都一样。RPC 像打电话托朋友办事：“帮我订张明早的票”“把 3 号订单取消掉”，你直接报出要做的事和参数，对方内部怎么折腾你并不关心。
取舍在哪里。最要紧的是幂等性（idempotency）：同一个请求发一次和发十次，结果是否相同。REST 规定 GET、PUT、DELETE 必须幂等，所以浏览器、CDN、反向代理可以放心缓存 GET 的结果，网络超时了重发一次也不怕。RPC 里的 addBalance() 天生不幂等，重试一次就多加一笔，得靠调用方自己加幂等键、去重表这类机制兜底。
可读性的口味也不同：GET /orders/42 一眼看出在说“42 号订单这个资源”；cancelOrder(42) 一眼看出在说“取消这个动作”。前者胜在结构统一、易被工具和缓存理解，后者胜在意图直白、方法多了也不别扭。
| 维度 | REST | RPC |
|---|---|---|
| 抽象单位 | 资源（名词） | 方法（动词） |
| 接口形态 | 少量 URL + 标准动词 | 一个方法一个入口 |
| 幂等性 | GET/PUT/DELETE 天然幂等 | 由方法语义决定，常不幂等 |
| 缓存 | 可直接复用 HTTP 缓存 | 需自行设计 |
| 可读性 | 资源层次清晰 | 动作意图清晰 |
| 常见场景 | 对外开放 API、增删改查 | 内部服务互调、动作型业务 |
对实际工作的意义：对外提供的、被第三方或浏览器大量读取的接口，REST 风格更省事，缓存和权限都能挂在 URL 上；内部服务之间高频、动作密集的调用，RPC 风格（如 gRPC 这类框架，具体能力以官方文档为准）写起来更贴近代码思维。两者并非对立：REST 风格的系统里放一个 POST /orders/42/cancel 这样的“动作型”接口，是业界很常见的务实做法。真正要守住的只有一条——想清楚哪些接口必须幂等、哪些结果可以被缓存，风格之争反而次要。