这是我参与「第三届青训营 -后端场」笔记创作活动的第1篇笔记

RESTful (Representational State Transfer)

表现层状态转移，由 HTTP 协议的主要设计者 Roy Fielding 提出。省略了主语 Resource。对资源的访问状态的变化通过url的变化表述出来，是一种以资源为中心的 web 软件架构风格。

REST描述的是在网络中client和server的一种交互形式。

用大白话来说，就是通过URL就知道要什么资源，通过HTTP方法就知道要干什么，通过HTTP状态码就知道结果如何。

HTTP方法：GET代表获取一个资源，POST代表添加一个资源，PUT代表修改一个资源，DELETE代表删除一个资源。

HTTP状态码：用来传递server的状态信息。比如最常用的200表示成功，500表示Server内部错误等。

优点

面向资源，风格统一，充分利用HTTP协议本身语义，具有自解释性
前后端分离，后端只负责提供数据接口，不再渲染模板，前端获取数据并呈现
- 前后端解耦，接口复用（前端和客户端公用接口），减少并发量
- 各司其职，前后端同步开发，提升工作效率。定义好接口规范
- 更有利于调试（mock）、测试和运维部署
可提供OpenAPI，便于第三方系统集成，提高互操作性
可提供无状态的服务接口，提高应用的水平扩展性

RPC (Remote Procedure Call Protocol)

远程过程调用协议，一个应用部署在A服务器上，想要调用B服务器上应用提供的方法。由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。

白话说，RPC就是可以实现客户端像调用本地服务方法一样调用服务器的服务。

RPC 的主要目标是让构建分布式应用更容易，在提供强大的远程调用能力时不损失本地调用的语义简洁性。为实现该目标，RPC 框架需提供一种透明调用机制让使用者不必显式的区分本地调用和远程调用。

RPC 和 REST 两者的定位不同，REST 面向资源，更注重接口的规范，因为要保证通用性更强，所以对外最好通过 REST。而 RPC 面向方法，主要用于函数方法的调用，可以适合更复杂通信需求的场景。实际上，HTTP协议比较多的还是前后端的通信，原因在于主流网页浏览器都支持HTTP协议，而且HTTP在缓存、幂等重试乃至cookie这种浏览器安全相关的方面也做了很多功夫。
从性能角度看，由于HTTP本身提供了丰富的状态功能与扩展功能，但也正由于HTTP提供的功能过多，导致在网络传输时，需要携带的信息更多，从性能角度上讲，较为低效。而RPC服务网络传输上仅传输与业务内容相关的数据，传输数据更小，性能更高。
RESTful API客户端与服务端之间采用的是同步机制，当发送HTTP请求时，客户端需要等待服务端的响应。当然对于这一点是可以通过一些技术来实现异步的机制的。
采用RESTful API，客户端与服务端之间虽然可以独立开发，但还是存在耦合。比如，客户端在发送请求的时，必须知道服务器的地址，且必须保证服务器正常工作。而 rpc + ralbbimq 中间件可以实现低耦合的分布式集群架构。

所属类别不同。REST 是一种软件架构风格。典型应用就是HTTP。RPC 可以基于 TCP/UDP，也可以基于 HTTP 协议进行传输的
使用方式不同。 HTTP 接口只关注服务提供方，对于客户端怎么调用并不关心，客户端并不知道具体方法。客户端只想获取资源，发起HTTP请求，而服务端接收到请求后根据URI经过一系列的路由定位到方法。接口只要保证有客户端调用时，返回对应的数据就行了。 RPC 则要求客户端接口保持和服务端的一致。RPC是服务端提供好方法给客户端调用，客户端需要知道服务端的具体类，具体方法，然后像调用本地方法一样直接调用它。
面向对象不同。从设计上来看，RPC面向方法，REST面向资源。
序列化协议不同。接口调用通常包含两个部分，序列化和通信协议。通信协议，REST 是基于 HTTP 协议，而 RPC 可以基于 TCP/UDP，也可以基于 HTTP 协议进行传输的。常见的序列化协议，有：json、xml、hession、protobuf、thrift、text、bytes等，REST 通常使用的是 JSON或者XML，而 RPC 使用的是 JSON-RPC，或者 XML-RPC。