什么是RESTful
随着移动互联网的发展，客户端层出不穷，app，web，微信端等等，而后端业务逻辑基于是一致的，如何做到业务逻辑“一次编写，随时接入”？答案是通过远程调用API，而目前比较火的方案是“Restful
api”。简单来说，RESTful API 是基于HTTP协议产生的一种相对简单的API设计方案，属于无状态传输。
本质： 一种软件架构风格
核心： 面向资源
解决的问题：
- 降低开发的复杂性
- 提高系统的可伸缩性
设计概念和准则
- 网络上的所有事物都可以被抽象为资源。
- 每一个资源都有唯一的自愿标识，对资源的操作不会改变这些标识。
- 所有的操作都是无状态的。
SOAP和REST的区别
如何设计RESTFul风格API（动物园为例）
资源路径
在RESTful架构中，每个网址代表一种资源，所以网址中不能有动词，只能有名词。一般来说API中的名词应该使用复数。
举例
举例来说，有一个API提供动物园（zoo）的信息，还包括各种动物和雇员的信息，则它的路径应该设计成下面这样。
https://api.example.com/v1/zoos //动物园资源
https://api.example.com/v1/animals //动物园资源
https://api.example.com/v1/employees //动物园资源
HTTP动词
对于资源的操作（CURD），由于HTTP动词（谓词）表示。
- GET：从服务器取出资源（一项或多项）。
- POST：在服务器新建一个资源。
- PUT：在服务器更新资源（客户端提供改变后的完整资源）
- PATCH：在服务器更新资源（客户端提供改变的属性）
- DELETE：从服务器删除资源。
举例 - POST/zoos:新建一个动物园
- GET/zoos/ID:获取某个指定动物园的信息
- PUT/zoos/ID:更新某个指定动物园的信息
- DELETE/zoos/ID:删除某个动物园
过滤信息
如果记录数量很多，服务器不可能都将它们返回给用户。
API应该提供参数，过滤结果
举例
- ?offset = 10：指定返回记录的开始位置。
- ?page = 2&per_page = 100：指定第几页，以及每页的记录数
- ?sortby = name&order = asc：指定返回结果排序，以及排序顺序。
- ?animal_tupe_id = 1：指定筛选条件。
状态码
错误处理
如果状态码是4xx或者5xx，就应该向用户返回出错信息。一般来说，返回的信息中将error作为键名，出错信息作为键值
{
“error”：“参数错误”
}
返回结果
针对不同操作，服务器向用户返回的结果应该符合以下规范：
- GET /collections :返回资源对象的列表（数组）
- GET /collections/identity :返回单个资源对象
- POST /collections :返回新生成的资源对象
- PUT /collections/identity :返回完整的资源对象
- PATCH /collections/identity :返回被修改的属性
- DELETE /collections/identity :返回一个空文档
REST风格的接口测试流程
测试方法
- 手动测试
借助工具完成
拼接参数执行请求 - 自动化测试
编写自动化脚本实现
一劳永逸，加入回归测试集合
需要一定编码经验
测试工具
常用的测试工具
Pastman
JMeter
ResClient等等
功能测试
测试覆盖：
业务流程
边界值，特殊字符
参数类型，必选项，可选项等
性能测试
测试覆盖：
并发数
吞吐量，tps
出错率等
安全性测试
测试覆盖
敏感数据加密
恶意攻击等
测试步骤
如何编写功能测试计划
如何使用Postman验证测试用例
GET测试用例
负向
- id不存在
POST测试用例
负向
- 多次添加name元素相同的数据
- name数据为空
- age数据不规范
PUT测试用例
反向
- id不存在
- name为空
PUT操作设计有问题，没有和POST操作一样的限制
DELETE测试用例
这里操作成功无返回，可使用GET操作遍历数据确认，可自己设置返回
- 删除不存在id数据