经常做接口测试,会看很多接口文档,那怎么识别研发的接口设计是否足够规范,是否符合一些行业标准或准则。那认识了解 RESTfull,可以让我们更具有专业性。让我们对接口文档的阅、接口合理性设计识别,做到有的放矢。
REST 全称是 Representational State Transfer,中文意思是表述(编者注:通常译为表征)性状态转移。
REST 本身并没有创造新的技术、组件或服务
REST 指的是一组架构约束条件和原则。如果一个架构符合 REST 的约束条件和原则,我们就称它为 RESTful 架构。
理论上 REST 架构风格并不是绑定在 HTTP 上,只不过目前 HTTP 是唯一与 REST 相关的实例。 所以我们这里描述的 REST 也是通过 HTTP 实现的 REST。
结合 REST 的原则,RESTfull 从下面几个方面做了约束和原则。
资源与URI
统一资源接口
资源的表述
资源的链接
状态的转移
所有的资源都有一个资源标志符
http://example.com/users/
http://example.com/class/
http://example.com/teacher/
幂等性:对同一REST接口的多次访问,得到的资源状态是相同的。
安全性:对该REST接口访问,不会使服务器端资源的状态发生改变。
示例
1.传统URL请求格式:
http://127.0.0.1/user/query/1 GET 根据用户id查询用户数据
http://127.0.0.1/user/save POST 新增用户
http://127.0.0.1/user/update POST 修改用户信息
http://127.0.0.1/user/delete GET/POST 删除用户信息
2.RESTful请求格式:
http://127.0.0.1/user/1 GET 根据用户id查询用户数据
http://127.0.0.1/user POST 新增用户
http://127.0.0.1/user PUT 修改用户信息
http://127.0.0.1/user DELETE 删除用户信息
服务端可以通过 Content-Type 告诉客户端资源的表述形式。
资源的表述形式有:文本资源可以采用 html、xml、json 等格式,图片可以使用 PNG 或 JPG 展现出来
很多人在设计 RESTful 架构时,使用很多时间来寻找漂亮的 URI,而忽略了超媒体。所以,应该多花一些时间来给资源的表述提供链接,而不是专注于"资源的 CRUD"。
比如下一页的链接地址、资源的链接地址都应该符合 RESTful 的设计思路。
原则上要求无状态通信原则。
这里说的无状态通信原则,并不是说客户端应用不能有状态,而是指服务端不应该保存客户端状态。
感兴趣的话,了解下 HTTP 为什么定义了这么多请求类型
扫一扫,关注我