RESTful 规范和Postman调试

什么是RESTful：
RESTful本质是一种软件架构风格，其核心是面向资源，能降低开发的复杂性和提高系统的可伸缩性。

设计概念和准则：
网络上的所有事物都可以被抽象为资源
每一个资源都有唯一的资源标识，对资源的操作不会改变这些标识。
所有的操作都是无状态的

SOAP和REST的区别
效率和易用性：

• SOAP由于各种需求不断扩充其本身协议的内容，导致在SOAP处理方面的性能有所下降。同时在易用性方面以及学习成本上也有所增加。
• RESTful由于其面向资源接口设计以及操作抽象简化了开发者的不良设计，同时也最大限度的利用了Http最初的应用协议设计理念。

安全性：

• RESTful对于资源型服务接口来说很合适,同时特别适合对于效率要求很高,但是对于安全要求不高的场景。
• SOAP的成熟性可以给需要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义，关键还是看应用场景。

安全性：SOAP会好于REST
效率和易用性：REST更胜一筹
成熟度：总的来说SOAP在成熟度上优于REST

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

资源路径（URI）–>HTTP动词 -->过滤信息–>状态码–>错误处理–>返回结果

资源路径：在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_ type_ id=1 :指定筛选条件。

状态码：服务器向用户返回的状态码和提示信息,使用标准HTTP状态码。

• 200 OK服务器成功返回用户请求的数据，该操作是幂等的。

• 201 CREATED新建或修改数据成功。

• 204 NO CONTENT删除数据成功。

• 400 BAD REQUEST用户发出的请求有错误，该操作是幂等的。

• 401 Unauthorized表示用户没有认证，无法进行当前操作。

• 403 Forbidden表示用户访问是被禁止的。

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

{
		"error":"参数错误"
	}

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

GET /collections :返回资源对象的列表(数组)
GET /collections/identity :返回单个资源对象
POST /collections :返回新生成的资源对象
PUT /collections/identity :返回完整的资源对象
PATCH / collections/identity :返回被修改的属性
DELETE / collections/identity : 返回一个空文档

REST风格的接口测试流程

了解接口格式—>编写测试用例—>测试用例评审—>开始测试—>完成测试报告—>结束

使用Postman验证测试用例