微服务——REST（Representational State Transfer，表述性状态转移）

面试造飞机系列：看架构师如何设计微服务接口

REST（Representational State Transfer，表述性状态转移）是一种软件架构风格。REST提出了一组架构约束条件和原则，任何满足 REST 约束条件和原则的架构，都称为 RESTful 架构。

微服务之间需要相互通信以完成特定的业务处理，在典型的客户端-服务端设计模型中，客户端和服务端通通过消息请求-响应的方式交互协作，REST 就是这样一套微服务之间交互接口的设计约束和原则规范。

表述性

「表述性」其实是缺少了主语的，主语是「资源」。完整的描述是「资源表述性」，也就是「资源的描述」。在网络通信中用什么描述资源呢？没错就是 URI（Uniform Resource Identifier，统一资源标识符）。

这里有几个近义词先给大家先科普一下：

URI 是统一资源标识符，用来唯一的标识一个资源。

URL 是统一资源定位器，它是一种具体的 URI，即 URL 可以用来标识一个资源，而且还指明了如何定位这个资源，URL 是 URI 的子集。

URN 统一资源命名，是通过名字来标识资源。URN也是 URI 的子集。

在 HTTP 协议中用 URL 标识资源，也就是浏览器地址栏你看到的那一串网址。

状态转移

搞懂了「资源描述性」接下来看下什么是「状态转移」？状态转移就是客户端通过一系列请求动作，推动服务端的资源状态发生变化，资源的状态可以在「创建-修改-查看-删除」之间转移。

资源状态转移

资源状态的变化在宏观上的反应就是业务流程推进。打个比方，你去银行系统开户、查余额、销户，这个过程你推动了你的银行账户这个「资源」经历了不同的状态转移让你完成了不同的业务操作。

REST的约束条件

协议选择

REST 本身并没有提到底层应该使用什么协议，日常实践案例中最常用的是基于 HTTP 的 RESTful 实现。

这是因为 HTTP 协议自带的动词 GET/POST/PUT/DELETE 可以作为推动状态转移的方法，另外HTTP 的制定了规范的状态码。还有其他的一些 HTTP 特性，这些特性使得在HTTP 之上实现 REST 要简单得多，而如果使用其他协议的话，就需要自己实现这些特性。

请求规范

RESTful 架构中，发生状态转换的是「资源」，所以URI 中一般只能包含代表「资源」的名词，并且推荐是复数，而不应该在 URI 中包对资源进行操作的动词。

对资源执行的CURD「增删改查」动作应该在HTTP请求方法的GET/POST/PUT/DELETE中体现。

符合REST规范的写法：

POST http://www.test.com/lemon // 创建

Get http://www.test.com/lemon // 查询

PUT http://www.test.com/lemon // 修改

DELETE http://www.test.com/lemon //删除

不符合REST规范的写法：

POST http://www.test.com/Createlemon // 创建POST http://www.test.com/Querylemon // 查询POST http://www.test.com/Modifylemon // 修改POST http://www.test.com/Deletelemon //删除

状态码

服务端消息响应携带状态码，指示客户端进行下一步处理。符合 RESTful 规范的接口返回状态码都是通用的，不需要额外约定，利用HTTP Status Code 状态码表示请求处理结果，降低了微服务间互操作成本。

状态码	状态码含义
2xx	成功，操作被成功接收并处理
3xx	重定向，需要进一步的操作以完成请求
4xx	客户端错误，请求包含语法错误或无法完成请求
5xx	服务器错误，服务器在处理请求的过程中发生了错误

下面是常见的HTTP状态码：

200 - 请求成功
301 - 资源（网页等）被永久转移到其它URL
404 - 请求的资源（网页等）不存在
500 - 内部服务器错误

无状态

RESTful接口要求是「无状态」。无状态指的是任意一个Web请求必须完全与其他请求隔离，当客户端发起请求时，消息本身包含了服务端识别这一请求上下文所需的全部信息。

无状态不是真的没有状态

接口「无状态」更确切的说是服务端无状态，整个会话还是需要状态维持的。要完成一个业务流程，一般客户端与服务端需要多次的消息交互，我们知道HTTP 协议是「无状态协议」，这就需要服务端能够识别几个独立 HTTP 请求的「状态信息」，从而将他们关联到一个业务流程中。

技术方案

服务端要能识别请求的「状态信息」，有两种技术方案：

Session 方式。服务端保存会话状态，客户端每次请求携带session-id。

服务端维护一个会话状态信息列表，用session-id唯一标识一个状态信息，session-id一般包含在HTTP响应的Set-Cookie头部返回给客户端，后续客户端请求携带包含session-id信息的cookie头部，服务端解析cookie取出session-id，去维护的状态列表中取回该消息对应的状态信息，这样就把无状态的HTTP变成有状态的了。

session会话

Token 方式。服务端不保存会话状态，客户端每次请求都携带完整的会话状态信息（一般是加密的）给服务端。

Token也称作是「令牌」或临时证书签名，状态信息都被加密到token中，这样每当服务器收到请求后解密token就能获取该请求对应的状态信息，也就能把不同的请求消息关联到同一个业务流程中来，和session方式有类似的效果，只不过这次的状态信息不保存在服务端。

Token会话

以上两种实现中，第一种 Session 方式是有状态的，第二种 Token 方式是无状态的。

如果你要实现 RESTful 接口最好按第二种技术方案实现，当然要实现无状态也还有其他方式，思路都是「服务端不保持会话状态」就对了。

为什么要无状态

为了高可用性和负载均衡需求，多个微服务通过负载均衡实现分布式集群化部署，集群中每个服务都是独立和对等的。如果服务器在收到客户端请求之时不可用或者宕机，无状态请求可以由任何其他可用服务器处理并作出应答，这在分布式应用中非常重要。

REST无状态接口

想象一下如果服务端保存状态，一个事务内的每个请求都必须落到同一台服务器去处理，这就失去了分布式的意义和优势。

所以， RESTful 接口要求是无状态的，是为了更好的适应分布式业务场景，发挥微服务集群优势。

REST 和 RPC

这两个概念经常出现在微服务架构设计中，REST 是一种软件架构接口设计风格，RPC 是一种计算机通信协议，看起来是两个不同的概念，没法比较。

但是有些书中把它们放在一起比较，真要比较的话，我个人倾向于把 REST 具体化为一种基于HTTP 并按照 REST 约束设计的通信协议，这样两个通信协议才有比较性。

回顾下RPC

RPC (Remote Procedure Call)远程过程调用是一个计算机通信协议。我们一般的程序调用是本地程序内部的调用，RPC允许你像调用本地函数一样去调用另一个程序的函数，这中间会涉及网络通信和进程间通信，但你无需知道实现细节，RPC框架为你屏蔽了底层实现。

RPC 是一种服务器-客户端Client/Server模式，经典实现是一个通过发送请求-接受回应进行信息交互的系统。

适用场景

很多 RPC 框架提供的消息传输都是基于二进制的，比如Thrift、Protocol buffers。这样做的好处是消息结构比较紧凑，对于频繁调用或者大流量、低时延要求的应用场景，能够显著减少网络开销；另一个约束是某些 RPC 框架有很强的技术耦合性，比如 Dubbo 只能用于 java 技术栈。综上，RPC 「更加适用于系统内部微服务之间的高效通信」

RESTful接口由于提供了统一的基于 HTTP的 REST 设计标准，只需 web 框架支持 HTTP 协议，并设计RESTful 风格的接口即可，极大的方便了第三方服务接入调用，REST「适合用于微服务系统对外暴露的接口设计标准」