在工作过程中不同程度地使用过 REST 和 RPC 来设计系统，对于使用过程中的优劣有一定的了解。
RPC 的使用感受
面向过程，就像是使用 C 语言也可以面向对象一样，精心设计一下 RPC 接口也可以有面向对象一样的体验。RPC 与程序员的思维非常接近，函数与 RPC 接口进行了精确的映射，有很多的工具或库能够自动将函数暴露为可远程进行调用的 RPC 接口，能够立即上手进行开发。容易产生细粒度的接口，大量的业务逻辑以及决策由客户端实现。
RPC 对传输、编解码进行了严格的定义，只要定义好接口，就可以藉由工具进行代码生成，使得开发人员只需要专注于业务逻辑开发。由于 RPC 没有对应用语义做任何定义，每个人设计的 RPC 接口差别会很大，需要客户端和服务器端紧密协作来完成开发。
REST 的使用感受
面向对象（资源），需预先按资源进行建模，有一些东西天生就不是面向资源的，比如：搜索、登录，则需要自由发挥，容易出现牵强的资源抽象。开发的前期会有明显的设计阶段。容易产生粗粒度的接口，大量的业务逻辑以及决策由服务端实现。
REST 没有对传输、编解码进行严格的定义，定义好资源后，需要手工进行编解码、HTTP 框架代码开发。由于 REST 对应用语义做了大量的定义，每个人设计的接口都是相似的，基于被广泛认可的设计规约，客户端和服务器端不容易产生大的分歧。
REST 是诗和远方
适用于开发 Internet 级别的应用。
也就是说服务的使用者遍布世界各地，服务可能会以意想不到的方式被访问。服务提供者（Server 端）与服务的使用者（Client 端）是不同的组织，以松耦合（loose coupling）的方式互相协作。
虽然存在大量被广泛接受的最佳实践，但并不存在官方的 REST 实现。不具体也就意味着开发者需要做很多的决定，比如需自行设计 URL、Content-Type、Encoding/Decoding 等。
RPC 是眼前的苟且
适用于开发 Intranet 级别的应用。
定下协议，生成框架代码，分别开发完应用模块，联调通过，上线，收工。
为什么要使用 REST
- 将控制权放在服务端
业务流程是由服务器控制的，客户端不需要完整理解业务逻辑。
- 通用的心理模型
如 HTTP 方法隐含的 冥等性 意义，通过 URL、Resource 展示出的业务模型（Model）。
- 重用基础设施
如 Nginx Proxy、Cache
什么时候不需要使用 REST
- 内部系统
Server 和 Client 是由同一个组织、团队进行开发。使用 gRPC 之类的技术可以获得更高的开发效率。
- 业务逻辑比较简单或者已经固化
REST 带来的弹性、扩展性并非刚需。
- 客户端与服务器之前的交互不是“请求－响应”模型
服务器需要通知客户端
结语
采用 REST 还是 RPC 对系统的根本复杂性影响较小，更多的是开发过程中会有不同的体验。