- 目录
- 1. RESTful是什么?
- 2. 设计概念和准则
- 3. HTTP协议介绍
- 4. HTTP响应协议
- 5. SOAP架构与RESTful架构区别
- 5.1 效率和易用性区别
- 5.2 安全性区别
- 6. 设计要素
- 6.1 资源路径
- 6.2 HTTP动词
- 6.3 过滤信息
- 6.4 状态码
- 6.5 错误处理
- 6.6 返回结果
- 7. 总结
1.RESTful是什么?
本质:一种软件架构风格
核心:面向对象
解决问题:降低开发复杂性;提高系统可伸缩性
2.设计概念和准则
- 网络上的所有事物都可以被抽象为资源.
- 每一个资源都有唯一的资源标识,对资源的操作不会改变这些标识.
- 所有操作都是无状态的.
3.HTTP协议介绍
HTTP是一个属于应用层的协议,特点是简捷和快速。
HTTP请求协议组成格式:
请求行 | 消息报头 | 请求正文 |
请求行格式:
Method Request-URI HTTP-Version CRLF
举例:
GET/HTTP/1.1 CRLF
请求方法:
- GET : 请求获取Request_URI所标识的资源
- POST : 在Request-URI所标识的资源后附加新的数据
- HEAD : 请求获取由Request_URI所标识的资源的响应消息报头
- PUT : 请求服务器存储一个资源,并用Request_URI作为其标识
- DELETE : 请求服务器删除Request_URI所标识的资源
- OPTIONS : 请求查询服务器的性能,或者查询与资源相关的选项和需求
4.HTTP响应协议
组成格式:
状态行 | 消息报头 | 响应正文 |
常用状态码:
- 200 OK 表示成功
- 400 Bad Request 表示客户端语法错误,不能被服务器所理解
- 401 Unaauthorized 表示服务器接受到请求但拒绝提供服务
- 404 Not Found 表示请求资源不存在
- 500 Internal Server Error 服务器错误
- 503 Server Unavailable 服务器不能处理客户端的请求
5.SOAP架构与RESTful架构区别
SOAP WebService是一种跨编辑语言和跨操作系统平台的远程调用技术.通过http协议发送请求和接受结果时采用XML格式封装,并增加一些特定的HTTP消息头,这些特定的HTTP消息头和XML内容格式就是SOAP协议.
5.1 效率和易用性区别
SOAP由于各种需求不断扩充其本身协议内容,导致在SOAP处理方面的性能有所下降,同时在易用性方面以及学习成本上有所增加.
而RESTful由于其面向资源接口设计以及操作抽象简化了开发者的不良设计,同时也最大限度的利用了HTTP最初的应用协议设计概念.
总结:SOAP的效率和易用性比不上RESTful
5.2 安全性区别
RESTful对于资源型服务接口来说很适合,同时特别适合对于效率要求很高,但对于安全要求不高的场景.
而SOAP的成熟性可以给需要提供给多开发语言的,对于安全性要求较高的接口设计带来便利.
总结:SOAP安全性比RESTful高
6.设计要素
设计流程:资源路径(URL)->状态码->HTTP动词->错误处理->过滤信息->返回结果
6.1 资源路径
在RESTful架构中,每个网址代表一种资源,所以网址中不能有动词,只能有名词,一般来说API中的名词要用复数.
举例:有一个API提供动物园的信息,还包括各种动物和雇员的信息,则资源路径设置如下
- https://api.example.com/v1/zoos //动物园资源
- https://api.example.com/v1/animals //动物资源
- https://api.example.com/v1/employees //雇员资源
6.2 HTTP动词
对资源的CURD操作,由于HTTP动词表示.
- GET : 从服务器取出一项或多项资源
- POST : 在服务器新建一个资源
- PUT : 在服务器更新资源(客户端提供改变后的完整资源)
- PATCH : 在服务器更新资源(客户端提供改变的属性)
- DELETE : 从服务器删除资源
举例:
- POST/zoos:新建一个动物园
- GET/zoos/ID:获取某个指定动物园信息
- PUT/zoos/ID:更新某个指定动物园信息
- DELETE/zoos/ID:删除某个动物园
6.3 过滤信息
如果记录数量很多,服务器不可能都将数据返回给用户,此时,API应该提供参数,过滤返回结果.
举例:
域名?page=2&&name=fangzhijie
6.4 状态码
服务器向用户返回的状态码和提供信息,使用标准的HTTP状态码.
- 200 OK 服务器成功返回用户请求数据,该操作是幂等的.
- 201 CREATED 新建或修改数据成功
- 204 NO CONTENT 删除数据成功
- 400 BAD REQUEST 用户发出的请求有错误,该操作是幂等.
- 401 Unauthrized 表示用户没有认证,无法进行当前操作
- 403 Forbidden 表示用户访问是被禁止的
- 422 Unprocesable Entity 当创建一个对象时候,发生一个检验错误.
- 500 INTERNAL SERVER ERROR 服务器发生错误,用户将无法判断发出的请求是否成功
6.5 错误处理
如果状态码是4xx或者5xx,就应该向用户返回出错信息.一般来说,返回的信息将error作为键名,出错信息作为键值即可,格式如下:
{
“error” : “参数错误”
}
6.6 返回结果
针对不同操作,服务器向用户返回结果应该符合以下规范:
- GET/collections : 返回资源对象列表(数组)
- GET/collections/identity : 返回单个资源对象
- POST/collections : 返回新生成的资源对象
- PUT/collections/identity : 返回完整的资源对象
- PATCH/collections/identity : 返回被修改的属性
- DELETE/collections/identity : 返回一个空文档
7.总结
上面就是我对RESTFUL API的基础概念总结,下面我还会出一章对RESTFUL API的实战篇,从实战看看要注意什么,接口究竟如何设计,最后,我们大家一起加油鸭~