一、REST的基本信息
什么是Restful，REST又是什么
首先Restful跟REST描述的是同一种东西，只是Restful是REST的形容词。
REST是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格。
它是一种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。REST是目前三种主流的Web服务实现方案之一。
REST本质：一种软件架构风格；REST核心：面向资源。
REST 把服务信息都抽象为资源。使用HTTP的GET、POST、PUT、DELETE 四种请求以完成资源查改增删，把对资源的操作抽象为CRUD，另外REST还有其他三种请求方式，具体如下。
| Method | 描述 | 安全性 | 幂等性 |
|---|---|---|---|
| GET | 从服务器获取资源(select) | √ | √ |
| POST | 在服务器新建一个资源(insert) | × | × |
| PUT | 在服务器更新资源(update) | × | √ |
| DELETE | 从服务器删除资源(delete) | × | √ |
| PATCH | 在服务器更新部分资源(很少使用，一般用post代替) | × | × |
| HEAD | 只从服务器获取资源的头部(select) | √ | √ |
| OPTIONS | 获取关于资源的哪些属性是客户端可以改变的 | √ | √ |
幂等性：是指无论调用多少次都不会有不同结果的 HTTP 方法。不管你调用一次，还是调用一百次，一千次，结果都是相同的。
问题来了，什么是资源？
资源可以是一张图片，一段文本，一首音乐，一个视频。
资源就是网络上的一个实体，或者说是网络上的一个具体信息。可以用一个URI（统一资源定位符）指向它，每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或独一无二的识别符 , URI。
REST提出了哪些设计概念和准则：
网络上的所有事物都被抽象为资源（resource）；
每个资源有一个唯一的资源标识（resource identifier）；
通过通用的连接器接口（generic connector interface）对资源进行操作；
对资源的各种操作不会改变资源标识；
所有的操作都是无状态的（stateless）。
二、SOAP和REST的区别
前面有说，REST是目前三种主流的Web服务实现方案之一，那么其他的又有哪些呢？
目前主流的Web服务实现方案有Rest、SOAP和XML-RPC。本文就只比较REST、SOAP的区别。
要比较，那么就先了解下SOAP的基本信息
什么是SOAP
SOAP是目前三大主流Web服务实现方案之一，是交换数据的一种协议规范，是一种轻量的、简单的、基于XML的标准通用标记语言下的一个子集的协议，它被设计成在WEB上交换结构化的和固化的信息。
SOAP语法规则：
SOAP 消息必须用 XML 来编码
SOAP 消息必须使用 SOAP Envelope 命名空间
SOAP 消息必须使用 SOAP Encoding 命名空间
SOAP 消息不能包含 DTD 引用
SOAP 消息不能包含 XML 处理指令
Soap的初衷
是作为一种轻量级解决方案出现的，采用xml格式定义过程调用和返回，一个Soap消息就是一个特定格式和内容的XML文档。
了解完SOAP，那么SOAP跟REST的区别在哪呢？本文从下面三点出发了解
安全性：SOAP优于REST。
SOAP在安全方面是通过使用XML-Security和XML-Signature两个规范组成了WS-Security来实现安全控制的，当前已经得到了各个厂商的支持，.net ，php ，java 都已经对其有了很好的支持（虽然在一些细节上还是有不兼容的问题，但是互通基本上是可以的）。
REST没有任何规范对于安全方面作说明，同时现在开放REST风格API的网站主要分成两种，一种是自定义了安全信息封装在消息中（其实这和SOAP没有什么区别），另外一种就是靠硬件SSL来保障,但是这只能够保证点到点的安全，如果是需要多点传输的话SSL就无能为力了。安全这块其实也是一个很大的问题，今年在BEA峰会上看到有演示采用SAML2实现的网站间SSO，其实是直接采用了XML-Security和XML-Signature，效率看起来也不是很高。未来REST规范化和通用化过程中的安全是否也会采用这两种规范，是未知的，但是加入的越多，REST失去它高效性的优势越多。
效率跟易用性：REST胜于SOAP
说到底REST是一种架构风格，即不是协议也不是标准，但是这种新的风格对现有的已存在的以SOAP为代表的web service造成的冲击是革命性的，所以之前很多用SOAP实现的方法正逐渐被REST取代
成熟度：SOAP高于REST
因为SOAP存在时间比较长，所以整体来说SOAP的成熟度高于REST
三、如何设计REST风格API
设计REST风格API应遵循以下六要素：
1、资源路径（URL）
在REST架构中，每个网址代表一种资源，所以网址中不能出现动词，只能有名词。一般来说API中的名词都应该使用复数。
以动物员（zoo）为例：
在这个URL中，首先使用的是https协议，https协议对比http协议来说，相对来说更安全点。其次是域名，这个没啥好说的。然后是版本号。版本号有两种写法，一种是像这个例子这样将版本号放在URL中，还有种是将版本号放在请求头中。最后是动物园名词复数。
接下来还有两个例子
https://api.example.com/v1/animals（动物资源例子）
https://api.example.com/v1/employees（动物园员工例子）
2、HTTP动词
对于资源的操作（CURD），由HTTP动词（谓词）表示。常见的GET,PUT,POST,DELETE,PATCH
还是以动物员（zoo）为例：
POST/zoos（新建动物园)
GET/zoos/{id}（获取某间动物园）
PUT/zoos/{id}（更新某间动物园信息）
DELETE/zoos/{id}（删除某间动物园）
3、过滤信息
若记录数很多，服务器不可能将信息全部返回给用户。API应提供参数，过滤返回结果。
举例：
?offset=10（指定返回记录的开始位置）
?page=2&per_page=100（指定第几页，以及每页的记录）
?sortby=name&order=asc（指定返回结果排序，以及排序顺序）
?animal_type_id=1（指定筛选条件）
4、状态码
服务器向用户返回的状态码和提示信息，使用标准HTTP状态码
| status | type | 描述 |
|---|---|---|
| 200 | OK | 服务器成功返回，该操作是幂等的 |
| 201 | CREATED | 新建或修改数据成功 |
| 204 | NO CONTENT | 删除数据成功 |
| 400 | BAD REQUEST | 用户发出的请求有错误，该操作是幂等的 |
| 401 | Unauthorized | 表示用户没有认证，无法进行当前操作 |
| 403 | Forbidden | 表示用户访问是被禁止的，没有权限访问 |
| 404 | Not Found | 表示资源不存在 |
| 422 | Unprocesable Entity | 当创建一个对象时，发生一个验证错误。 |
| 500 | INTERNAL SERVER ERROR | 服务器发生错误 |
| 503 | SERVICE UNAVAILABLE | 服务器当前无法处理请求 |
总体来说，
2开头都是成功的，4开头基本上都是用户端的错误，5开头都是服务器端的问题
5、错误处理
如果状态码是4跟5开头，就应该像用户返回错误信息，一般来说，
返回的信息中将error作为键名，出错信息作为键值即可
{
"error":"错误参数"
}
6、返回结果
针对不同操作，服务器向用户返回的结果应符合以下规范
GET/collections：返回资源对象列表/数组
GET/collections/identity：返回单个资源对象
POST/collections：返回新生成的资源对象
PUT/collections/identity：返回完整的资源对象
PATCH/collections/identity：返回被修改的属性
DELETE/collections/identity：返回一个空文档
四、REST风格的API测试流程
1、测试API有两种测试方法：
手动测试
借助工具，拼接参数执行需要的测试请求
自动化测试
编写自动化脚本（python, java）实现，一劳永逸，加入回归测试集合
项目使用自动化持续集成，两者结合就更加完美了，我们可以将编写好的
脚本加入回归测试集合之后，每天定时的启动自动化持续集成项目，通过
这种方法可以及时快速的发现后续的代码变动对之前的功能的影响，通过这种
方法，我们可以发现很多回归的问题。但是这种方法需要测试人员有一定的
编码经验
哪种方法更好？
在编写脚本的过程中也需要借助工具用手动的方法来验证参数的正确性
请求的正确性。在实际的测试中尽量使用自动化测试方法，一劳永逸。
2、测试工具有哪些
postman：是一款功能强大的网页调试与发送网页HTTP请求的Chrome插件，可以通过Chrome的应用商店进行搜索并安装。不过由于2017年官方宣布chrome停止对chrome应用程序的支持，postman插件可能无法正常使用了。目前chrome应用商店能使用的就是chrome扩展程序和主题背景。在这里建议大家直接下载它的应用程序进行使用
下载地址：https://www.postman.com/
JMeter：主要是做性能跟压力测试的，但是也可以做API测试
官方地址：https://jmeter.apache.org/
TestClient：直接给个安装学习的网址：API Test WebApiTestClient工具安装及使用
3、测试覆盖范围：
功能测试：业务流程，边界值、特殊字符，参数类型、必选项、可选项等
性能测试：并发数，吞吐量、tps，出错率
安全性测试：敏感数据加密（密码等），恶意攻击等
4、测试步骤：
五、如何编写功能测试计划
网络上只要你输入“如何编写功能测试计划”，就会有一大坨的测试计划怎么写，但是本文不是按照那些正规测试人员编写的计划来写的计划，这儿只是写个大概的测试计划，嘿嘿。
模拟业务需求
<meta charset="utf-8">
GET :http://localhost:8080/API/Users/list
header : Content-Type = application/json
body : 空
Response : 返回所有User对象
Status code : 200<meta charset="utf-8">
GET :http://localhost:8080/API/Users/{id}
header : Content-Type = application/json
body : 空
Response : 返回所有指定id的对象
Status code : 200
测试计划
业务流程 - GET：
正向用例：返回所有对象和返回某一个对象
负向用例：URL输入不正确业务流程 - GET：
正向用例：返回所有对象和返回某一个对象
负向用例：一个不存在id
URL输入不正确
若想学习正规的功能测试计划，这儿有个网址：软件测试计划如何编写
六、如何使用Postman验证测试用例
第一个用例
正向测试用例
Tests里验证测试结果信息
测试结果：
负向测试用例：
测试结果：
第二个用例
正向测试
测试结果
负向测试
无效id
结果
URL错误
结果
学习REST地址：
Restflu API 实践
REST API接口测试
