关于 REST 与 RPC 的一些思索

在工作过程中不同程度地使用过 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 对系统的根本复杂性影响较小,更多的是开发过程中会有不同的体验。


web