REST服务集成微服务架构倾向于使用轻量级的通信机制（通常是HTTP提供的API调用方式）实现服务之间的交互，基于API优先的服务契约管理成为微服务架构的重要原则之一。REST在HTTP的基础上提供了一系列架构约束和原则，帮助微服务更好地实现通信和集成。
REST API
REST的全称为Representational State Transfer，中文翻译为“表述性状态转移”或“表现层状态变化”。如果一个架构符合REST原则，则称它为RESTful架构。
REST与HTTP
首先要说明的是，虽然HTTP（1.0版本和1.1版本）的主要设计者和REST概念的提出者是同一个人，但是REST和HTTP有着本质的区别。
HTTP本身是万维网的支撑协议，也是一项通用协议规范，而REST描述的则是客户端与服务端的一种交互形式。下面介绍HTTP和REST的主要区别。
● HTTP的详细内容可以参考RFC2616。HTTP采用了请求/响应模式。客户端向服务端发送一个请求，请求头包含请求的方法、URI、协议版本，以及请求修饰符、客户信息和内容的类似于MIME的消息结构。服务端以一个状态行作为响应，相应的内容包括消息协议的版本、成功或者错误编码加上服务端信息、实体元信息及可能的实体内容。
● REST本身并没有创造新的技术、组件、服务，隐藏在REST背后的理念是使用Web标准的现有特征和能力，强调Web组件交互的可扩展性、接口的独立性、减少交互延迟中间件。它的目标是更好地利用现有Web标准中的准则和规范，关注的是系统之间的通信行为细节，以及如何改进通信机制的表现。
REST与JSON
在服务集成交互技术中，我们已经介绍了两种主要的基于文本的序列化方式：JSON和XML。二进制格式的交互更多应用于RPC方式的交互集成，例如Google的Protocol Buffer和Facebook的Thrift。在REST的序列化方式上，从灵活性的角度说，JSON无论从数据格式还是使用方式上都更加简单。JSON相比XML，无论在结构的紧凑性还是对浏览器的兼容性上，JSON都有得天独厚的优势。
从序列化的性能方面来说，JSON没有过多的标签，JSON主要基于键值对的形式表示数据，所以传输和处理速度都有巨大的优势。
从对象的表述和数据结构与宿主语言的对应方面来看，JSON有更明显的优势，例如哈希表（Hashtable）、键值对（Key/Value）、向量（Vector）、列表（List）及对象组成的数据结构。XML在表达数据结构和对象的转换上都没有JSON方便。
当然XML也有JSON所不具备的优势，像通过标签可以添加属性来存储元数据（Metadata），可以使用连接进行超媒体控制等，当然我个人还是比较倾向于使用JSON。
REST中的重要概念
REST从语义层面将响应结果定义为资源，并使用HTTP的标准动词映射作为对资源的操作，形成了一种以资源为核心、以HTTP为操作方式的，与语言无关、平台无关的服务间的通信机制，如下图所示是REST的重要概念。
“资源”是REST中的重要概念，REST中的表现层状态转移的主语就是“资源”。“资源”就是网络中的一个实体，或者说是网络上的一个具体的信息，你可以使用URI（统一资源定位符）指向它，资源总是需要某种格式的载体，可以使用HTML、XML或者JSON表述资源内容。
“表述”就是资源在某个特殊时刻具体呈现出来的形式和描述。
一种资源可能有多种表述形式，而URI应该只代表资源的位置，它的具体表述形式应该在HTTP请求的头信息中用Accept和Content-Type字段指定，这两个字段才是对“表现层”的描述。
“状态转移”是指在客户端与服务端互动的过程中，通过某种手段实现对数据状态的变更。在HTTP中，GET用来获取资源、POST用来创建资源或者更新资源、PUT用来更新资源、DELETE用来删除资源。
“统一接口”包含一组受限的预定义操作，不论什么样的资源，都可以通过相同的接口进行资源的访问。接口应该使用标准的HTTP方法，如GET、PUT和POST，并遵循这些方法的语义。
REST成熟度模型
Leonard Richardson发明的REST成熟度模型可以帮助我们更好地使用REST，如下图所示。
Level 0：本层级是REST的最低级别，仅把HTTP作为传输协议来传输数据，还可以把SOAP、JSON-RPC都看成此类，仅仅使用请求/响应模式的通信风格来传递“Plain Old XML”。HTTP可降级为类似TCP的传输层协议。HTTP中的方法不包含业务逻辑语义。
Level 1：本层引入了资源概念，每个资源对应后端的URI资源标识符，HTTP向服务资源端点（Service End-Point）发送POST请求，并向方法中添加参数。
Level 2：使用的API严格根据HTTP的Web语法执行对资源的处理和约束，例如GET用于读取资源、POST用于创建资源、PUT用于更新资源、DELETE用于删除资源。
Level 3：API基于HATEOAS原则设计，简单地说就是响应消息中包含后续操作的URI资源，Level 3拥有协议自描述功能。HATEOAS也是REST的高级形态，一个显而易见的好处是，客户端通过返回结果中的Link资源，可以更好地理解业务、适应变化。同时，这些链接对客户端和服务端也进行了解耦，你不再需要调整客户端来适应服务端的修改，通过双向的语义关联就可以更好地实现前后端分离。
RESTful架构
RESTful架构是一种典型的Client-Server架构，但是强调瘦服务端，服务端只应该处理跟数据有关的操作，所有RESTful架构显示相关的 工 作 都 应 该 放 在 客 户 端 。REST 的 约 束 因 素 有 Client-Server 、Stateless、Cache、Uniform Interface、Layered System、Code-onDemand。下图是我们总结的RESTful架构的特征和核心原则。
● 服务器是无状态的，服务端不会保存客户端的会话状态数据，所有状态信息都在双方沟通的消息中。
● 服务器是幂等的，对于相同请求，服务端返回的数据应该相同，所以服务端可以缓存结果，结果可以存储在服务端，也可以存储在客户端。
● 所有操作都基于统一接口（Uniform Interface）的方式进行，每个资源应该都是唯一的。
● 通过客户端来处理资源，也就是说客户端不能直接操作服务端的资源，只能通过响应表达式操作，并发送响应请求，最后由服务端处理资源并返回。
● 客户端和服务端传送的任何一个消息都是自描述的，处理消息需要的上下文都应该被包含在这个消息中。
● 在REST分层结构中，在Client-Server之前也可以加入Proxy层和Gateway层，这些中间层可以加入业务逻辑处理，例如安全控制、负载均衡。
● Code-On-Demand，客户端可以访问服务端的资源，但是并不知道处理服务器返回的结果，而这个处理过程的代码应该是从服务端发送过来的，然后在客户端执行，也就是说客户端的功能是根据需求动态从服务端获得的，这个特性在REST中是可选的。
REST API的接入
在传统的电信领域，我们使用CORBA（Common ObjectRequestBroker Architecture，公共对象请求代理体系结构）进行跨平台的交互，通过分布式对象调用来实现分布式架构，CORBA规范规定了ORB（Object Request Broker，对象请求代理）的标准体系。
虽然CORBA有非常严格的API契约机制和规范，然而CORBA的缺陷也是非常明显的，它是制约跨平台的技术发展的重要因素。
● CORBA是面向对象的分布式架构体系，将分布式机制完全绑定为以对象为中心的互操作模式，给分布式系统带来了极大的耦合性，给对象属性的变更带来了复杂性，也带来了不确定性，这个缺陷一直延续到了EJB时代。
● CORBA 使 用 专 有 的 二 进 制 协 议 ， 通 过 IDL （ InterfaceDescription Language，接口描述语言）绑定和允许应用程序之间的互操作协议。通过编译IDL文件可以生成桩代码和框架。协议的复杂性和庞杂的语义规范都增加了开发和运维的难度。SOAP也有CORBA类似的复杂信息交换协议机制，使用XML数据格式，它定义了一整套复杂的标签，WSDL（WebServices Description Language，Web服务描述语言）用来描述服务器地址和接口规范，XML传输效率问题也是SOAP的另一个问题。
REST本身使用HTTP，充分利用了HTTP的平台中立性和网络透传等优势。另外，最重要的是REST基于HTTP抽象资源的分布式调用，将分布式调用绑定在资源的操作上面，而在REST中，资源是一个抽象的概念，资源本身使用URI表示，与具体实现无关，这样就给REST带来了更好的解耦性。下面总结一下使用REST的好处：
● REST非常简单，基于HTTP，没有过多的模式限制。
● REST对浏览器友好，有众多工具和生态支持HTTP Client，例如可以使用curl、postman等工具和插件来测试HTTP-API。
● 支持请求/响应的通信方式。
● HTTP对防火墙友好。
● 通信不需要带中间件，简化了系统架构。
可以说，REST已然成为API开发集成的事实标准。当然，REST没有强制的IDL来定义API，不过目前在社区中也有很多流行的REST IDL规范，使用比较广泛的就是Swagger，它可以作为开发和记录REST API的工具，我们后续章节会加以介绍。下面我们来看一个虚拟的项目：在线商品服务介绍REST API规范接入手册。
REST API请求示例
【协议描述】
请求URL结构： https://domain/api/server/class？params，其中各字段含义如下：
● domain，请求地址的HOST&&PORT，假设域名为test.cn。
● api/server，固定值，服务所在的相对路径。
● class，具体调用方法的URL，参考下文的接口列表。● params，公共请求参数，参考下文的请求参数。
【请求方式】
● 公共请求头参数有Timestamp时间戳，请将其置于HTTP API的请求头中。Timestamp为本请求的UNIX时间戳，用于确认请求的有效期，以秒为单位。
● URL内参数中包含可变字段，如/orders/orderid，orderid为URL内参数，需要对应填值，具体参考下文的接口列表。
● 对于POST请求参数，传递的参数必须使用JSON格式，公共请求参数仍置于URL中，具体方式可参考下文的代码示例。
【返回结果】
API接口使用标准HTTP返回码，只有2XX才是正确返回，下面是可能的返回码汇总：
● 200，请求成功，具体请求结果参考响应内容JSON值。
● 400，多数情况下是指请求参数错误或请求不合法。
● 401，sign值计算错误，或App已被删除。
● 404，设备或对应的App信息不存在，将返回NotFound错误。
● 50X，服务器错误，服务器内部数据或逻辑有误。
【REST API示例】
1.订单列表
● 描述：获取所有订单ID列表
● 路径：/orders
● 方法：GET
● 参数：page，count
curl-X GET
https://test.cn/api/server/ordersH"Timestamp:1529051966"
2.订单详细信息查询
● 描述：获取指定设备详细信息
● 路径：/orders/orderid
● 方法：GET● 参数：无
curl-X
GET
https://test.cn/api/server/orders/1234562342-H"Timestamp:1529051966"
3.更新订单信息
● 描述：为设备更名，或禁用/恢复设备
● 路径：/orders/orderid
● 方法：PUT
● 参数：无
curl-X GET
https://test.cn/api/server/orders/1234562342_-H"Timestamp:1529051966"
本文给大家讲解的内容是系统集成服务集成交互技术：REST服务集成，REST API
- 下篇文章给大家讲解的内容是系统集成服务集成交互技术：REST服务集成，Swagger接口文档规范
- 觉得文章不错的朋友可以转发此文关注小编；
- 感谢大家的支持！
本文就是愿天堂没有BUG给大家分享的内容，大家有收获的话可以分享下，想学习更多的话可以到微信公众号里找我，我等你哦。
