一. 简介
1. RPC(remote procedure call)
执行远程服务器上的一个function,，像调用本地服务(方法)一样调用服务器的服务(方法)。通常的实现有 XML-RPC , JSON-RPC , 通信方式基本相同, 所不同的只是传输数据的格式.
(1) 优点：
设计简洁，便于理解
轻量的payload
很高的性能表现
(2) 缺点：
前后端代码高耦合
代码可读性不好，相关代码不容易被定位
会导致有大量被定义的函数，难以管理
(3) 核心
RPC是分布式架构的核心，按响应方式分如下两种：
同步调用：客户端调用服务方方法，等待直到服务方返回结果或者超时，再继续自己的操作
异步调用：客户端把消息发送给中间件，不再等待服务端返回，直接继续自己的操作。
同步调用的实现方式有WebService和RMI。Web Service提供的服务是基于web容器的，底层使用http协议，因而适合不同语言异构系统间的调用。RMI实际上是Java语言的RPC实现，允许方法返回 Java 对象以及基本数据类型，适合用于JAVA语言构建的不同系统间的调用。
异步调用的JAVA实现版就是JMS(Java Message Service)，目前开源的的JMS中间件有Apache社区的ActiveMQ、Kafka消息中间件，另外有阿里的RocketMQ。
2. REST(Representational state transfer)， 表现层状态转移
在设计API时，使用路径定位资源，方法定义操作，通过Content-Type和Accept来协商资源的类型
REST是一种架构风格，指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。REST规范把所有内容都视为资源，网络上一切皆资源。
REST并没有创造新的技术，组件或服务，只是使用Web的现有特征和能力。 可以完全通过HTTP协议实现，使用 HTTP 协议处理数据通信。REST架构对资源的操作包括获取、创建、修改和删除资源的操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。
REST即表述性状态传递（Representational State Transfer，简称REST），是一种软件架构风格。REST通过HTTP协议定义的通用动词方法(GET、PUT、DELETE、POST) ，以URI对网络资源进行唯一标识，响应端根据请求端的不同需求，通过无状态通信，对其请求的资源进行表述。
(1) 优点：
前后端高度解耦
便于理解，即使没有看文档，也能大概知道接口是用来做什么的；
接口的功能有单一性，便于扩展和复用；
利用了HTTP原本的特性
(2) 缺点：
有时payload会变的特别大
同一个页面可能要调用很多个API，来获取不同的东西，在网络差的情况下会降低体验
(3) 特征：
资源：资源是以json(或其他Representation)为载体的、面向用户的一组数据集，资源对信息的表达倾向于概念模型中的数据
无状态:所谓无状态的，即所有的资源，都可以通过URI定位，而且这个定位与其他资源无关，也不会因为其他资源的变化而改变。
统一的接口:RESTful架构风格规定，数据的元操作，即CRUD(create, read, update和delete,即数据的增删查改)操作，分别对应于HTTP方法：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源，这样就统一了数据操作的接口，仅通过HTTP方法，就可以完成对数据的所有增删查改工作。
URI:可以用一个URI（统一资源定位符）指向资源，即每个URI都对应一个特定的资源。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或识别符
(4) 设计原则：
网络上的所有事物都被抽象为资源
每个资源都有一个唯一的资源标识符
同一个资源具有多种表现形式(xml,json等)
对资源的各种操作不会改变资源标识符
所有的操作都是无状态的
无状态通信，是指服务端(响应端)不保存任何与特定HTTP请求相关的资源，应用状态必须由请求方在请求过程中提供。要求在网络通信过程中，任意一个Web请求必须与其他请求隔离，当请求端提出请求时，请求本身包含了响应端为响应这一请求所需的全部信息
简单的来说就是状态信息保存在服务器的就是有状态的，而状态信息保存在客户端的就是无状态的。通过REST的无状态原则恰好有利于实现负载均衡，在分布式的Web系统上，有多个可用的服务器，每个服务器都可以处理客户端发来的请求，及时有一台服务器宕机，无状态的请求可以交给别的服务器处理，这是有状态的请求所做不到的。
RESTful即实现REST设计风格的一种架构，如RESTful API（REST设计风格的API）
(5) 风格
利用HTTP方法让接口统一化
利用HTTP状态码返回状态信息
3. GraphQL (Graph query language)
吸取了RPC和REST的一些共同优点；以查询为基本单元，方便获取到想要的数据，
(1) 优点：
低网络速度下表现优异
声明式地数据获取
根据UI需求获取合适的数据，避免不必要的数据传输
(2) 缺点：
定义起来相对复杂
缓存问题，需要一个更加健全的机制中来确保字段级别的缓存
版本持续更新中，还不太成熟
二. 比较：
1. RPC服务提供方与调用方接口依赖方式太强，会导致编码的复杂性，而REST接口相比RPC更为轻量化，服务提供方和调用方的依赖只是依靠一纸契约，不存在代码级别的强依赖。
2. RPC服务对平台敏感，难以简单复用：REST可以实现跨平台，任何一个语言的调用方都可以根据接口定义来实现。
3. Dubbo采用的RPC的服务调用，SpringCloud采用的REST。
4. 通信协议.REST使用HTTP,RPC一般使用TCP
5. 性能,REST性能低,RPC性能高
6. 灵活度,REST灵活度高,RPC灵活度低
7. 从使用方面看，Http接口只关注服务提供方（服务端），对于客户端怎么调用，调用方式怎样并不关心，通常情况下，客户端使用Http方式进行调用时，只要将内容进行传输即可，这样客户端在使用时，需要更关注网络方面的传输，比较不适用与业务方面的开发；而RPC服务则需要客户端接口与服务端保持一致，服务端提供一个方法，客户端通过接口直接发起调用，业务开发人员仅需要关注业务方法的调用即可，不再关注网络传输的细节，在开发上更为高效。
8. 从性能角度看，使用Http时，Http本身提供了丰富的状态功能与扩展功能，但也正由于Http提供的功能过多，导致在网络传输时，需要携带的信息更多，从性能角度上讲，较为低效。而RPC服务网络传输上仅传输与业务内容相关的数据，传输数据更小，性能更高。
二. 适用场景
基于RPC的API更加适用行为(也就是命令和过程)，基于REST的API更加适用于构建模型(也就是资源和实体)，处理CRUD。REST使用HTTP的方法，例如：GET,POST,PUT,DELETE,OPTIONS还有比较不常用的PATCH方法。RPC通常只会使用GET和POST方法，GET方法通常用来获取信息，POST方法可以用来进行所有的行为。
三. 总结
1. RPC：所谓的远程过程调用 (面向方法)
SOA：所谓的面向服务的架构(面向消息)
REST：所谓的 Representational state transfer (面向资源)
2. 设计API时，决定使用哪种形式，得先考虑所设计的API将会被谁使用：
如果是关注于对象和资源的项目，需要对接各种不同的端和使用者，需要便于使用和阅读文档，那么适合使用REST
如果是面向行为动作，或者内部的一些微服务，对响应要求高，那么可以考虑RPC
如果是需要给UI提供数据，或者需要对弱网络环境下优化而减少请求，那么可以考虑GraphQL
面向终端用户的尽量用Restful HTTP。原因是认知广，直观，编程语言都支持HTTP（包括shell，这样调试起来方便），性能不是那么重要，方便用户share链接。
面向内部系统的话如果机器不多也可以考虑用Restful HTTP，如果机器很多还是尽量用二进制的RPC吧，毕竟性能差距还是很大的。
REST调用及测试都很方便，RPC就显得有点繁琐，但是RPC的效率是毋庸置疑的，所以建议在多系统之间的内部调用采用RPC。对外提供的服务，Rest更加合适。
RESTful API和RPC是两种完全不同概念的东西，是没法放在一起比较的，如果硬要将它俩比较，我认为RESTful是RPC的一种实现，即RPC包括RESTful API，但RPC不等于RESTful API。
RPC：我认为RPC是一种为实现远程调用而提出一种思想，至于你用什么方式去达到目的都可以（例如：用什么网络协议来传输数据看自己的选择）。
RESTful API：符合REST设计风格的一种接口架构，它也是通过网络进行的远程调用，但是远程调用仅限于HTTP。
