RPC 和 REST还有RESTFul到底是个什么玩意？

背景

1. 公司两位同事，讨论对外提供接口的时候返回的状态码应该是怎样的，A同事，业务逻辑有问题，请求成功且OK，状态码就应该返回2XX，另一个同事说应该返回5XX，原因是通过网关来监控服务的调用和处理情况。听了个大概，然后说到了RPC和RESTful，所以我得看看

一 什么是RPC？

1. wiki百科:在分布式计算，远程过程调用（英语：Remote Procedure Call，缩写为 RPC）是一个计算机通信协议。该协议允许运行于一台计算机的程序调用另一个地址空间（通常为一个开放网络的一台计算机）的子程序，而程序员就像调用本地程序一样，无需额外地为这个交互作用编程（无需关注细节）。RPC是一种服务器-客户端（Client/Server）模式，经典实现是一个通过发送请求-接受回应进行信息交互的系统。
2. RPC就是一种思想既不是规范也不是协议，基于这种思想实现的框架就是RPC框架如dubbo,springcloud,grpc。也就是将多个服务集成到一块可以让应用之间高效调用。其实我一直纳闷这不就是http接口调用啊。 再想想http是信息之间传输的规范协议。两者不能胡混。再细品一下，RPC远程过程调用，首先就是”远“非本机，在这个过程中使用其他的框架和技术达到高效调用。
3. 在一个典型 RPC 的使用场景中，包含了服务发现、负载、容错、网络传输、序列化等组件，其中“RPC 协议”就指明了程序如何进行网络传输和序列化。

在这里插入图片描述

1. 就是我们平时在写简单的接口的时候，让其他服务调用那算不算远程调用呢？这肯定不算吧。因为你不能像调用本地方法那样去调用暴露接口的方法，因为你还得写HTTP请求等等。。

二 什么是REST

1. 先看看wiki百科： 表现层状态转换（英语：Representational State Transfer，缩写：REST）是Roy Thomas Fielding博士于2000年在他的博士论文[1]中提出来的一种万维网软件架构风格，目的是便于不同软件/程序在网络（例如互联网）中互相传递信息。表现层状态转换是根基于超文本传输协议（HTTP）之上而确定的一组约束和属性，是一种设计提供万维网络服务的软件构建风格。符合或兼容于这种架构风格（简称为 REST 或 RESTful）的网络服务，允许客户端发出以统一资源标识符访问和操作网络资源的请求，而与预先定义好的无状态操作集一致化。因此表现层状态转换提供了在互联网络的计算系统之间，彼此资源可交互使用的协作性质（interoperability）。相对于其它种类的网络服务，例如SOAP服务，则是以本身所定义的操作集，来访问网络上的资源。 通过上面的描述我的理解:在HTTP、URI、XML以及HTML这些现有的广泛流行的协议和标准上，在对软件开发者所提供的交互API定义了统一规范 " 其实我们在平时讨论的应该就是这个基于REST的RESTFul API。
2. 符合REST设计风格的Web API称为RESTful API：
3. 资源是由URI来指定： 如我们在查询一个用户的信息的时候直接将用户的ID拼接在URI上如：

https://zh.qq.org/id/123456

直接在QQ获取ID为123456的用户。 2. 对资源的操作包括获取、创建、修改和删除，这些操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。例如：我们在使用CSDN的时候，在上传文章的时候REST规范就是你后台提供的API是使用的是HTTP 中是的POST方法。在删除文章的时候使用DELETE方法。

在这里插入图片描述

1. 利用HTTP状态码返回状态信息，就如上面同事讨论的那样，那到底返回多少呢？ 在HTTP规范中(来自HTTP权威指南)：“200——299在客户端发起请求时，这些请求都是成功的。”很难理解这个请求到底怎么就是成功了。是请求达到服务器且有返回，还是在前面这个确定的情况下业务逻辑也正常返回了？在rest规范好像是也没有明确定义，这个成功到底是怎么一个成功呢？但是最为一个小白，个人感觉请求成功就是请求成功，服务端和客户端在HTTP连接的过程中是没有什么问题的，不应该有业务逻辑上的含义。支持我们的A同事。

• 在SpringBoot中可以自定义反馈状态码。其实这个操作大概也就是为了符合Rest的风格搞的吧(自己YY)，以后到自己写也大概知道如何去写吧。附上一篇自定义HTTP状态码的文章（https://www.jianshu.com/p/ee15d544d000）
• HTTP 状态码的含义：https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

1. 利用HTTP报头告知对方如何处理本次请求（相应） HTTP报头是描述客户端与服务器之间的请求或者响应应该如何处理本次请求的，比如该用什么表现形式。

Authorization 认证报头 
Cache-Control 缓存报头 
Cnotent-Type  消息体类型报头

1. 无状态 REST设计风格要求Server无状态，无状态并不等于不保存用户的状态，而是指服务器不保存请求状态（会话信息），客户端必须每次都带上自己的状态去请求服务器，如果确实要维持用户的状态，也应由客户端负责，例如：在服务端上通过Cookie保存Token，之后的请求中都带上Token，而这个Token就保存有了用户的状态（如登录信息）。这里需要注意的是：

• 通过Session保存状态不是REST设计风格，因为Session是将状态信息（用户信息、过期时间等）保存在了服务器上，比如用户登录成功后，会将Session信息保存在服务器，然后返回个SessionID给客户端并且将SessionID保存在Cookies中,之后的请求客户端都会通过Cookies传递SessionID给服务器，服务器根据客户端传来的SessionID去匹配之前保存的Session状态信息，所以这个状态是保存在服务器上的，是靠服务器维持的，所以不是REST设计风格。
• 通过Token保存状态是REST设计风格，因为状态信息（用户信息、过期时间等）都是保存在Token中，而Token又是保存在客户端中（如Cookies），比如用户登录成功后，服务器会返回一个Token（包含了用户信息、过期时间等）给服务端，服务端将Token保存在Cookies中，之后的请求客户端都会取出Token放到Request Headers中传给服务器，服务器验证Token的有效性即可。

RPC 和 rest 的区别是？？

简单对比 RPC 和 Restful API

面对对象不同：

RPC 更侧重于动作。 REST 的主体是资源。 RESTful 是面向资源的设计架构，但在系统中有很多对象不能抽象成资源，比如登录，修改密码等而 RPC 可以通过动作去操作资源。所以在操作的全面性上 RPC 大于 RESTful。

传输效率：

RPC 效率更高。RPC，使用自定义的 TCP 协议，可以让请求报文体积更小，或者使用 HTTP2 协议，也可以很好的减少报文的体积，提高传输效率。 复杂度：

RPC 实现复杂，流程繁琐。 REST 调用及测试都很方便。 RPC 实现(参见***节)需要实现编码，序列化，网络传输等。而 RESTful 不要关注这些，RESTful 实现更简单。

灵活性：

HTTP 相对更规范，更标准，更通用，无论哪种语言都支持 HTTP 协议。 RPC 可以实现跨语言调用，但整体灵活性不如 RESTful。