Rest API

REST 是Representational state transfer 的缩写。

它定义了一种网络应用软件的架构风格或者说特性。具有这些风格特性的应用软件架构，可以称之为 RESTful 的软件架构。

注意，REST并非一种软件架构（包括接口）设计规范，而是一种风格的描述。 这点和基于SOAP的web service 不同。

很多同学对这点不太理解。

什么叫 是一种设计的风格特性，而不是具体的设计规范呢？

我们打个比方，如果我们要制造一个餐桌， 会有具体的制造规范，比如下图所示， 各个部分的规格尺寸有详细的定义。

这个可以对应设计规范的概念。

如果我们并不确定具体的部件规格，而是说明了，各种部件设计样式 怎样的风格，就是 欧式风格，如下图

这个对应设计风格的概念。

所以REST 并不是非常具体的设计规范，而是一些设计上的风格约束。

怎样的风格约束才是REST的？

那么REST大体提出了怎样的设计风格的约束呢？有如下这些

 - 客户端和服务器结构

 - 连接协议具有无状态性：确保系统的横向拓展能力

 - 能够利用Cache机制增进性能

 - 层次化的系统

 最重要的，REST对客户端服务端的接口设计有如下要求：

l 每个资源都有其标志（URI）, 服务请求中标志要操作的资源的URI 。

所谓资源，其实就是系统中的任何可操作的对象， 比如在线学习系统中： 用户、用户的金币、 课程、 题目、试卷等等，都是资源

客户端访问这些资源的时候， 服务请求用uri标记资源，比如

http://api.example.com/users/13

可以表示id为13的用户（也可以叫做用户资源）

l 通过操作资源的表现形式 (representation) 操作资源

可以用HTML，XML，SVG，JSON，PNG等各种格式返回请求URI所标志的资源。

这些格式是所标志的资源的表现形式 (representation)。

服务端可以返回的资源的表现种类可能有多种， 客户端可以通过HTTP请求的Accept 头告诉服务端，它想要什么样的 资源的表现形式（就是什么格式）

l 请求和响应消息 应该包含足够的信息描述 该消息，以便接受者理解，

包含足够的信息 才能做到 无状态性 （不需要上下文， 消息里面就包含了足够的信息）

另外，可以用HTTP请求的方法（GET/ POST/ PUT/ DELETE等）来 描述这条消息是完成什么类型的操作，比如添加、删除、修改、查看 资源

比如：添加用户资源， 可以用 POST方法

从上述约束可以看出，REST对系统设计前后端接口部分的要求只是一些 风格上的，并没有定义一个新的明确的接口规范。

举个例子，我们怎么接待客人？

甲公司的要求是：必须穿藏青色西装、白色衬衫、带红色领带，刚见面时必须鞠躬，请客人到会客厅入座时，前行引路时到转弯处，必须说：这边请，等等。 这样定义了一套完整的规范。 这就对应于基于SOAP的Web Service

乙公司的要求是：穿着上要让客户感到规范，见面时的动作要让客户感到对他的尊敬，给客人引路时要主动，等等。 这样说出了接待时各动作要达到的效果，但并不明确说明具体的做法。 这个对应REST的概念。

行业现状

REST只是说明了一种设计风格。 所以并没有一个标准的REST设计规范。

很多web系统前端和后端的接口无非就是针对资源的 CRUD操作 （增查改删）, 正好对应了REST的接口  风格特性 的 一部分。 这些操作用HTTP协议来实现本身就并不复杂，不需要像 基于SOAP的Web Service 定义那样的一套人类难读懂的规范。

而且REST并不规定具体的实现规范：比如消息的编码格式。 实现方式比较灵活简单。 这就使得后来的系统设计者很容易就倾向于 REST 而不是基于SOAP的Web Service。

我们可以发现事实上，目前RESTful 的设计已经  逐渐成为 网络软件系统（包括web系统，移动APP系统）的主流实现方式。

其实众多开发者对REST的理解程度不同， 设计出来的系统有的并非完成遵循REST风格。由于REST是如此的火热， 大家都声称自己的系统是RESTful的。

很多系统前后端接口其实就是 基于HTTP 的CRUD操作，就号称是RESTful的。 我们也不必深究。只要能较好的满足目前系统的需求就行。

这个就像过去 很多皇帝都声称自己的治国策略是孔孟思想治国， 其实他们对孔孟的认识各有不同（甚至有的差异很大）， 但是可能都具备了孔孟思想的一些特征 。  我个人觉得 与其纠结于到底该怎样做到每个细节才是正宗的孔孟思想 ， 不如 就大体采用一些孔孟思想理论，能解决实际问题就可以了，至于有些细节不那么符合 孔孟思想的原意也无伤大雅。

所谓REST API 就是满足 REST风格特性的Web 服务接口。

由于 REST是目前的行业主流，所以我的接口测试主要针对 REST API进行

web服务接口测试的常用方法

对web服务接口（主要是REST接口）测试，可以使用现有的工具软件，也可以自己使用编程语言利用一些库进行开发

使用第三方工具

现在市场上有很多支持web服务接口（主要是REST接口）测试的工具。

这些工具，最基本的都是可以模拟构建HTTP请求消息，并且解析收到的HTTP响应消息。大家可以根据自己的需求，选择使用。

一般学会了一种，其它的核心功能基本类似。

松勤的自动化课程以其中一款Postman为例介绍，如何使用工具进行web服务接口测试。

自己开发工具

利用编程语言（比如Python语言）和一些库，自行构造HTTP请求消息，并且解析收到的HTTP响应消息。

这种方式更加适用于完全的自动化，并且和自动化框架结合起来使用。

松勤的自动化课程也会讲解一些例子。