什么是RPC？什么是Restful？它们有什么区别？( 四 ) _RPC

controller
性能
较高
较低
接口依赖
有
无
灵活/开放性
较低
较高
开发成本
较低
较高
RPC主要是基于TCP/IP的，而RESTful服务主要是基于HTTP的。HTTP是在传输层协议（TCP）之上的，由于RPC普遍采用二进制压缩的序列化参数，数据传输量方面会比REST风格的json（或者XML）小很多。所以总的来说，从运行效率来看，RPC当然是要更胜一筹。RESTful的优势主要体现在通用、开放、标准方面。两者的优缺点详细说明如下，以方便读者在实际应用项目中进行综合分析选择。
（1）RPC的优点。

对于服务器端的开发人员而言，容易设计、开发。
对于消费者而言，调用非常简单。
便于做集中的监控。
基于socket的二进制RPC协议，建立连接延迟低、网络传输效率高。
支持有状态的长连接，可进行双向通信，实时性好。
在各个企业的使用较为成熟，许多企业都有自己的RPC实践，并已广泛应用在生产环节。

（2）RPC的缺点。

紧耦合：API一旦发布，就难以再做改动。客户端必须使用特定的框架，而且需要引入API包。
没有统一的设计风格：增加了客户端开发人员的学习成本。难以实现通用的客户端库，每个RPC框架都有各自的协议。通常以动词的形式设计API，一个功能就增加一个API，设计时很少考虑领域模型。
掩盖网络的复杂性：开发人员很容易混淆远程调用与本地调用。实际上网络调用与本地调用是完全不同的，RPC的调用方式，让使用者很难意识到是在进行网络调用，忽略了针对网络复杂性的处理。这样会损害用户（客户端）可感知的性能。

（3）RESTful API的优点。

使用HTTP作为应用层协议（注意：不是传输层），没有耦合性。
可以使用浏览器扩展（如Postman）或者curl之类的命令行来测试RESTful API 。
客户端使用任意支持HTTP的工具即可。使用类似Netflix Feign这样的专门设计的工具，可以做到接近RPC的调用方式。
可以方便地发布到外网环境。
HTTP对防火墙友好，可以设置各种安全策略。
基于资源的设计思想，强迫设计人员抽象资源，思考模型，使设计人员加深对业务模型的理解。
不需要中间代理，简化了系统架构。

（4）RESTful API的缺点。
传统的观念认为RESTful API不具备RPC的很多特性，不能作为企业级应用广泛使用的API管理方式。实际上只要能够正确实施，RESTful API也可以具备RPC 框架的许多特性。

误解1：RESTful API 不便于集中管理。

基于“服务发现”和“API网关”，RESTful API服务也可以实现统一的服务注册、服务发现，“API网关”可作为服务的统一出口，反向代理全部的底层服务，实现统一的安全控制和权限管理。

误解2：RESTful API 不便于客户端调用。

RESTful API直接使用HTTP作为应用层协议，实际上只要支持HTTP的任何工具都可以完成对RESTful API的调用，Web层也可以使用原生JavaScript或jQuery调用。
不可否认，传统的HTTP操作库一般只是支持HTTP隧道模式的调用方式，即把HTTP作为传输协议，针对媒体类型转换也没有特殊处理，只返回数据流或者文本数据，对资源的概念也没有特别设计，如Apache Http Components、jQuery等。
但是目前已经有很多专门针对RESTful API编写的客户端调用工具，如Java的Netflix Feign、Sping RestTemplate 。Feign使用基于注解的形式定义客户端接口，框架会自动生成本地代理类，直接使用类似于本地方法调用的形式调用。Spring Cloud项目下的Spring Cloud Netflix Feign子项目结合了Spring Boot和Netflix Feign做了封装，更便于使用。
再者在前端领域，现在成熟的前端框架都提供了Resource插件，专门用于RESTful 接口的操作，如Vue下的vue-resource，AngularJS的ng-resource等，针对RESTful API的调用以及资源导航都做了很优秀的设计。
相关书籍企业级云原生架构技术、服务与实践