你了解过系统集成服务集成交互技术：REST服务集成——RESTAPI吗

REST服务集成微服务架构倾向于使用轻量级的通信机制（通常是HTTP提供的API调用方式）实现服务之间的交互，基于API优先的服务契约管理成为微服务架构的重要原则之一。REST在HTTP的基础上提供了一系列架构约束和原则，帮助微服务更好地实现通信和集成。REST APIREST的全称为Representational State Transfer，中文翻译为“表述性状态转移”或“表现层状态变化”。

ikt4435

912人浏览 · 2022-04-11 16:38:09

ikt4435 · 2022-04-11 16:38:09 发布

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才是正确返回，下面是可能的返回码汇总：