此文包含内容

1）什么是RESTful
2）SOAP和REST的区别
3）如何设计RESTFul风格API（动物园为例）
4）REST风格的接口测试流程
5）如何编写功能测试计划
6）如何使用Postman验证测试用例

1.什么是RESTful

RESTFUL是一种网络应用程序的设计风格和开发方式，基于HTTP，可以使用XML格式定义或JSON格式定义。RESTFUL适用于移动互联网厂商作为业务使能接口的场景，实现第三方OTT调用移动网络资源的功能，动作类型为新增、变更、删除所调用资源。（百度百科）

REST全称是Representational State Transfer，中文意思是表述（编者注：通常译为表征）性状态转移。它首次出现在2000年Roy Fielding的博士论文中，Roy Fielding是HTTP规范的主要编写者之一。他在论文中提到："我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。REST指的是一组架构约束条件和原则。" 如果一个架构符合REST的约束条件和原则，我们就称它为RESTful架构。

REST本身并没有创造新的技术、组件或服务，而隐藏在RESTful背后的理念就是使用Web的现有特征和能力，更好地使用现有Web标准中的一些准则和约束。虽然REST本身受Web技术的影响很深，但是理论上REST架构风格并不是绑定在HTTP上，只不过目前HTTP是唯一与REST相关的实例。（菜鸟教程）

restful

REST架构的主要原则
· 对网络上所有的资源都有一个资源标志符。
· 对资源的操作不会改变标识符。
· 同一资源有多种表现形式（xml、json）
· 所有操作都是无状态的（Stateless）:使得客户端和服务器端不必保存对方的详细信息，服务器只需要处理当前的请求，不需了解请求的历史。可以更容易的释放资源，让服务器利用Pool（连接池）技术来提高稳定性和性能。

符合上述REST原则的架构方式称为RESTful
RESTful是一种常见的REST应用，是遵循REST风格的web服务，REST式的web服务是一种ROA（面向资源的架构）。

RESTful资源操作

资源请求格式

2.SOAP和REST的区别

SOAP

简单对象访问协议是一种基于 XML 的协议，可以和现存的许多因特网协议和格式结合使用，包括超文本传输协议（HTTP），简单邮件传输协议（SMTP），多用途网际邮件扩充协议（MIME），基于“通用”传输协议是 SOAP的一个优点。它还支持从消息系统到远程过程调用等大量的应用程序。SOAP提供了一系列的标准，如WSRM（WS-Reliable Messaging）形式化契约确保可靠性与安全性，确保异步处理与调用；WS-Security、WS-Transactions和WS-Coordination等标准提供了上下文信息与对话状态管理

相对RESTful而言，SOAP协议属于复杂的、重量级的协议
REST是一种轻量级的Web Service架构风格，其实现和操作比SOAP和XML-RPC更为简洁，可以完全通过HTTP协议实现，还可以利用缓存Cache来提高响应速度，性能、效率和易用性上都优于SOAP协议。REST架构对资源的操作包括获取、创建、修改和删除资源的操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法，这种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。REST架构尤其适用于完全无状态的CRUD（Create、Read、Update、Delete，创建、读取、更新、删除）操作。

区别

核心：在SOAP模式把HTTP作为一种通信协议，而不是应用协议。所以http中的表头，错误信息等全部无视。实际上http有 put get post delete等方法。
REST 则不然，HTTP method中的 POST GET PUT DELETE 都是与请求方法对应的，rest真正实现了http的五层结构。
REST 提交的请求中，代理服务器可以通过请求方式直接判断请求动作是要进行什么操作。
REST 轻量级，SOAP重量级；
REST 学习起来比较简单，容易上手，SOAP相对来说难些回；
REST 能通过http形式的直接调用，基于JSON，SOAP通过XML传输；
REST 效率和速度来说相对快些答，SOAP则稍逊一筹

3.如何设计RESTFul风格API（动物园为例）

设计

1.资源路径（URI）

在RESTful架构中，每个网址代表一种资源（resource），所以网址中不能有动词，只能有名词，而且所用的名词往往与数据库的表名对应，一般来说，数据库中的表都是同种记录的”集合”（collection），所以API中的名词也应该使用复数。

有一个API提供动物园（zoo）的信息，还包括各种动物和雇员的信息，则它的路径应该设计成下面这样。

   https://api.example.com/v1/zoos
   https://api.example.com/v1/animals
   https://api.example.com/v1/employees

2.HTTP动词

对于资源的具体操作类型，由HTTP动词表示。

常用的HTTP动词有下面五个（括号里是对应的SQL命令）。

·GET（SELECT）：从服务器取出资源（一项或多项）。
·POST（CREATE）：在服务器新建一个资源。
·PUT（UPDATE）：在服务器更新资源（客户端提供改变后的完整资源）。
·PATCH（UPDATE）：在服务器更新资源（客户端提供改变的属性）。
·DELETE（DELETE）：从服务器删除资源。

还有两个不常用的HTTP动词。

HEAD：获取资源的元数据。
OPTIONS：获取信息，关于资源的哪些属性是客户端可以改变的。

下面是一些例子。

GET /zoos：列出所有动物园

POST /zoos：新建一个动物园

GET /zoos/ID：获取某个指定动物园的信息

PUT /zoos/ID：更新某个指定动物园的信息（提供该动物园的全部信息）

PATCH /zoos/ID：更新某个指定动物园的信息（提供该动物园的部分信息）

DELETE /zoos/ID：删除某个动物园

GET /zoos/ID/animals：列出某个指定动物园的所有动物

DELETE /zoos/ID/animals/ID：删除某个指定动物园的指定动物

3.过滤信息（Filtering）

如果记录数量很多，服务器不可能都将它们返回给用户。API应该提供参数，过滤返回结果。

下面是一些常见的参数。

?limit=10：指定返回记录的数量

?offset=10：指定返回记录的开始位置。

?page=2&per_page=100：指定第几页，以及每页的记录数。

?sortby=name&order=asc：指定返回结果按照哪个属性排序，以及排序顺序。

?animal_type_id=1：指定筛选条件

参数的设计允许存在冗余，即允许API路径和URL参数偶尔有重复。比如
GET /zoo/ID/animals
与
GET /animals?zoo_id=ID 的含义是相同的。

4.状态码（Status Codes）

服务器向用户返回的状态码和提示信息，常见的有以下一些（方括号中是该状态码对应的HTTP动词）。

200 OK - [GET]：服务器成功返回用户请求的数据，该操作是幂等的（Idempotent）。

201 CREATED - [POST/PUT/PATCH]：用户新建或修改数据成功。

202 Accepted - [*]：表示一个请求已经进入后台排队（异步任务）

204 NO CONTENT - [DELETE]：用户删除数据成功。

400 INVALID REQUEST - [POST/PUT/PATCH]：用户发出的请求有错误，服务器没有进行新建或修改数据的操作，该操作是幂等的。

401 Unauthorized - [*]：表示用户没有权限（令牌、用户名、密码错误）。

403 Forbidden - [*] 表示用户得到授权（与401错误相对），但是访问是被禁止的。

404 NOT FOUND - [*]：用户发出的请求针对的是不存在的记录，服务器没有进行操作，该操作是幂等的。

406 Not Acceptable - [GET]：用户请求的格式不可得（比如用户请求JSON格式，但是只有XML格式）。

410 Gone -[GET]：用户请求的资源被永久删除，且不会再得到的。

422 Unprocesable entity - [POST/PUT/PATCH] 当创建一个对象时，发生一个验证错误。

500 INTERNAL SERVER ERROR - [*]：服务器发生错误，用户将无法判断发出的请求是否成功。

状态码的完全列表参见这里。

5.错误处理（Error handling）

如果状态码是4xx，就应该向用户返回出错信息。一般来说，返回的信息中将error作为键名，出错信息作为键值即可。

{
    error: "Invalid API key"
}

6.返回结果

针对不同操作，服务器向用户返回的结果应该符合以下规范。

*GET /collection：返回资源对象的列表（数组）
*GET /collection/resource：返回单个资源对象
*POST /collection：返回新生成的资源对象
*PUT /collection/resource：返回完整的资源对象
*PATCH /collection/resource：返回完整的资源对象
*DELETE /collection/resource：返回一个空文档

4.REST风格的接口测试流程

接口测试有称为API测试，接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。

手动测试

自动测试

功能测试

性能测试

安全测试

测试步骤

REST风格接口测试

5.如何编写功能测试计划

需求描述

功能点的拆分、接口测试
get 、delete、put、post的URL明确
Header ：格式
body：测试效果
Response：修改user对象

业务流程

正向用例：返回需求效果
负向用例：各种错误可能

get

post

put

delete

测试计划

6.如何使用Postman验证测试用例

Postman是一个接口测试工具，在做接口测试的时候，Postman相当于一个客户端，它可以模拟用户发起的各类HTTP请求，将请求数据发送至服务端，获取对应的响应结果，

从而验证响应中的结果数据是否和预期值相匹配；并确保开发人员能够及时处理接口中的bug，进而保证产品上线之后的稳定性和安全性。

它主要是用来模拟各种HTTP请求的(如:get/post/delete/put..等等),Postman与浏览器的区别在于，

有的浏览器不能输出Json格式，而Postman更直观接口返回的结果

RESTful