Spring Boot中REST与RPC有何核心区别？二者是否相似？

二者的共通点 #

• 都属于跨进程、跨网络的服务通信方案，核心作用都是实现不同部署节点之间的功能调用
• 都可以基于HTTP协议传输：这是最容易造成混淆的点。RPC并不强制绑定TCP私有协议，目前主流的RPC框架比如gRPC、Dubbo都支持HTTP/2甚至HTTP/1.1作为传输层协议；而REST本身就是基于HTTP设计的架构风格，当二者都跑在HTTP上时，从请求形式上看相似度很高
• 都可以实现CRUD类基础数据操作：业务功能的实现逻辑和架构风格没有绑定关系，不管用RPC还是REST，都能完成新增、查询、修改、删除这类基础操作，这也是“用Spring Boot写几个CRUD接口就算做了REST API”这个误区的来源。

核心差异 #

二者最本质的区别是抽象维度完全不同：RPC的抽象对象是远程过程（方法），目标是让开发者调用远程服务时能获得和调用本地方法一致的体验；REST的抽象对象是资源，目标是通过统一的HTTP语义实现对资源状态的标准化操作。具体差异体现在以下几个方面：

• 设计逻辑不同
  RPC的核心逻辑是屏蔽网络通信的底层细节，开发者只需要关心要调用的目标方法名、入参、返回值即可，不需要感知网络传输的过程。比如调用远程的用户查询方法时，代码写法和调用本地同签名的userService.getUserById(1L)没有区别。
  REST的核心逻辑是把所有业务实体抽象为可定位的资源，所有接口操作本质都是对资源状态的修改，开发者需要先定位到具体资源，再通过标准HTTP语义执行对应操作。
• 语义绑定规则不同
  RPC本身不强制绑定传输协议的语义，哪怕用HTTP作为传输载体，HTTP方法、状态码都只是传输工具，没有强制约束。比如很多HTTP形式的RPC接口会统一用POST发送所有请求，把要调用的方法名、参数全部放在请求体里，完全不使用GET、DELETE等其他HTTP方法，响应也统一返回200状态码，业务层面的成功失败、错误信息全部放在响应体里自定义解析。
  REST强依赖HTTP标准语义做接口约束：GET对应资源查询、POST对应资源创建、PUT对应资源全量更新、DELETE对应资源删除，HTTP状态码也要匹配实际的请求结果——比如资源不存在返回404、权限不足返回403、参数错误返回400、服务端异常返回500。这也是为什么说“仅用Spring Boot实现CRUD不等于做了REST API”：很多开发者写的接口路径带明确动作（比如/getUser、/deleteOrder）、所有操作全用POST、所有响应统一返回200，本质就是套了HTTP外壳的RPC，完全不符合REST的设计要求。
• 适用场景不同
  RPC的接口和方法签名强绑定，客户端与服务端的耦合度更高，不需要遵循公共的接口规范，只要调用双方对齐方法定义即可，序列化一般采用Protobuf、Hessian等高效二进制协议，性能更好，更适合企业内部微服务之间的高频调用。
  REST的接口遵循统一的HTTP规范，耦合度更低，可读性更强，哪怕调用方没有拿到详细接口文档，只要熟悉REST设计规则，也能大致推断出接口的使用方式，更适合对外公开的公共API、跨团队的跨域接口调用。
• 序列化灵活性不同
  RPC不强制要求序列化格式，为了追求性能通常会采用体积更小、解析速度更快的二进制序列化协议，不需要强制使用文本格式。
  REST通常采用JSON、XML等人类可读的文本格式作为资源表述，调试成本更低，但序列化性能和传输效率普遍低于二进制RPC方案。

快速判断方法：如果你的接口路径包含动作类词汇、所有操作都统一用POST请求、所有响应不管对错都返回200状态码，那不管你用什么框架实现，本质都是跑在HTTP上的RPC接口，不是REST API。

内容的提问来源于stack exchange，提问作者Mussawir Ahmad Paul