Web3领域为何选择RPC而非REST？前端开发者的技术疑问

作为Web3前端开发者，你熟悉REST的资源型架构，但区块链场景的特殊性让RPC成为更适配的选择，核心优势集中在这几点：

• 完全匹配区块链的操作模型
  区块链节点的核心工作是处理「状态查询」和「指令执行」两类操作，RPC的远程过程调用模式直接对应"调用节点上的特定方法"——比如用eth_getBalance查余额、eth_sendTransaction发交易，完全贴合区块链原生的逻辑。而REST的资源CRUD模型需要把这些操作强行映射成资源的增删改查，反而多了一层冗余抽象，不符合区块链的操作习惯。

• 原生支持批量调用，降低网络开销
  Web3前端经常需要一次性执行多个查询（比如同时查多个地址余额、多笔交易详情），RPC（比如JSON-RPC）原生支持批量请求，可以把多个方法调用打包成一个HTTP请求发送，大幅减少网络往返次数。REST原生没有批量调用能力，要实现类似效果得额外做请求合并或依赖GraphQL，成本更高。

• 标准化的方法签名，跨节点兼容性强
  区块链生态里的节点遵循统一的RPC规范（比如以太坊JSON-RPC），不管连接哪个兼容节点，eth_getBlockByNumber这类方法的参数、返回格式都是一致的。而REST没有统一标准，不同服务商可能设计出完全不同的接口路径和参数规则，前端适配不同节点时要做大量兼容工作。

• 原生支持双向通信，适配实时场景
  区块链需要实时监听链上事件（比如新块生成、交易确认），RPC（尤其是WebSocket版的JSON-RPC）原生支持订阅模式，比如eth_subscribe可以直接监听指定事件。REST是单向请求响应模型，要实现实时推送得额外搭建WebSocket服务或做轮询，复杂度更高。

• 轻量高效的请求负载
  RPC的请求体是紧凑的JSON结构，示例如下：

{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x742d35Cc6634C0532925a3b8D4C557cccccccccc","latest"],"id":1}

相比REST不需要在URL里拼接资源路径、查询参数，解析速度更快，在高频调用场景下能显著提升性能。

内容的提问来源于stack exchange，提问作者Jisang Seo