一、概念
1.1 REST概念
REST(Representation State Transfer):资源表述性状态转移,是一种结构风格。
Resource:“资源”,网络上的一个实体,或者说网络上一个具体信息。它可以是一段文字、一张图片、一首歌曲、一种服务,总之就是一个具体的实在。你可以用一个URL(统一资源定位符)指向它,每种资源对应一个特定的URL。要获取这个资源,访问它的URL就可以,因此URL就成了每一个资源地址或独一无二的识别符。(一切皆资源,URL用于资源的唯一标识)。
Representation:“资源”是一种信息实体,它可以有多种外在表现形式。我们把资源具体呈现出来的形式,叫做它的“表现层”。比如:文本可以用txt格式、HTML格式、XML格式、JSON格式表现,甚至可以采用二进制格式;图片可以用jpg、png、gif格式表现。(1.资源以什么样的表现形式呈现出来2.资源的表现层一般都在请求头信息中体现出来)。
State Transfer:访问一个网站,就代表了客户端和服务器的一个互动过程。在这个过程中,势必涉及到数据和状态变化。互联网通信协议HTTP协议,是一个无状态的协议。这意味着,所有状态都保存在服务端。因此,如果客户端要操作服务器,必须通过某种手段,让服务器端发送“状态转化”(state Transfer)。而这种转化是建立在表现层之上的,所以就是“表现层状态转化”。(1.在客户端和服务器的交互过程中,涉及到状态的转化,我们通过某种手段(ajax、form)让它进行转换)。
Uniform Interface:REST要求,必须通过统一的接口来对资源执行各种操作。对于每个资源只能执行一组有限的操作。
HTTP1.1协议为例:
7个HTTP方法:GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS
HTTP头信息(可自定义)
HTTP响应状态码(可自定义)
这些就是HTTP1.1协议提供的统一接口
REST还要求,对于资源的执行操作,其操作语义必须由HTTP消息体之前部分完全表达,不能将操作语义封装在HTTP消息体内部。(1.使用7个HTTP方法来体现对资源的操作,不在url地址中体现) RE
1.2 REST原则
网络上所有事物都被抽象为资源
每个资源都有一个唯一的资源标识符
同一个资源具有多种表现形式(xml,html,json)
对资源的操作不会改变资源标识符
所有的操作都是无状态的
1.3 RESTful
restful:遵守了rest原则的web服务。
理解:restful与rest相比,多了一个ful, 就英语层面来说是一个形容词,restful翻译为中文为: “rest式的” , 是rest式的什么呢?答案是 rest式的应用,rest风格的web服务也是rest式的应用,rest式的web服务是一种ROA(The Resource-Oriented Architecture)(面向资源的架构),ROA听起来很高大上有没有。
两者联系与区别: restful是由rest派生出来的。
1.4 API
API是Application Programming Interface(应用程序接口)的缩写,它是拿来描述一个类库的特征或是如何去运用它。
1
系统的接口:很多情况下,需要把系统功能作为服务暴露给外部的其他应用使用或者给移动端使用,就需要把系统中的服务作为 接口暴露出去,一般分为公共接口(发短信、天气预报)和私用接口(公司内部使用)。
1.5 REST API
基于RESTful架构的一套互联网分布式的API设计理论.
1
1. 6 到底什么是RESTful架构
每一个URL代表一种资源
客户端和服务器之间,传递这种资源的某种表现层
客户端通过HTTP动词,对服务端资源进行操作,实现“表现层状态转换”
二、RESTFul Api设计
2.1 协议
API与用户的通信协议,通常使用HTTP(S)协议。
2.2 域名
应该将API部署在专用域名之下。
http://api.rock.com
如果确定API很简单,不会有大规模扩充,可以考虑放在主域名之下。
http://www.rock.com/api/
2.3 版本
应该将API的版本号放入URL。
http://api.rock.com/v1/
也有做法是将版本号放在HTTP的头信息中,但不如放在URL中方便和直观。GITHUB是这么搞的。
2.4 路径(Endpoint)
路径又称“终点”(endpoint),表示API的具体网址。
在RESTFul架构中,每个网址代表一种资源(Resource),所以网址中不能有动词,只能有名词,而且所用的名词往往与数据库的表格名对应。一般来说,数据库中的表都是同种记录的“集合”(collection),所以API中的名词也应该使用复数。
2.5 HTTP动词
对于资源的具体操作类型,由HTTP动词表示。
HTTP常用动词
GET(select):从服务器获取资源(一项或多项)
POST(create or update):在服务器新建资源
DELETE(delete):从服务器删除资源
PUT(update):在服务器更新资源(客户端提供改变后的完整资源)。PUT更新整个对象
PATCH(update):在服务器更新资源(客户端提供改变属性【补丁】)。PATCH更新个别属性
HEAD:获得一个资源的元数据,比如一个资源的hash值或者最后修改日期
OPTIONS:获得客户端针对一个资源能够实施的操作(获取该资源的api(能够对资源做什么操作的描述))。
动作示例
GET zoos/:列出所有动物园
POST zoos/:新建一个动物园
GET zoos/ID:获取某个指定动物园的信息
PUT zoos/ID:更新某个指定动物园的信息(提供该动物园的全部信息)
PATCH zoos/ID:更新某个指定动物园的信息(提供该动物园的部分信息)
DELETE zoos/ID:删除某个动物园
GET zoos/ID/animals:列出某个指定动物园的所有动物
2.6 过滤信息(Filtering)
如果记录数量过多,服务器不可能将它们返回给用户。API应该提供参数,过滤返回结果。
?limit=10
?offset=10
?page=2&per_page=20
?sorted=name&order=desc
student_id=id
参数设计允许存在冗余,即允许API路径和URL参数偶尔有重复,比如: GET /students/id和?student_id=id
2.7 状态码
服务器向用户返回的状态码和提示信息,常见的有以下一些地方。
200 OK -[GET]:服务器成功返回用户请求的数据
201 CREATE-[POST/PUT/PATCH]:用户新建或修改数据成功
202 Accepted-[*]:表示一个请求已经进入后台排队(异步任务)
204 No CONTENT-[DELETE]:表示数据删除成功
400 INVALID REQUEST-[POST/PUT/PATCH]:用户发出请求有错误
401 Unauthorized -[*]:表示用户没有权限(令牌,用户名,密码错误)
403 Forbidden-[*]:表示用户得到授权,但是访问是被禁止的
404 Not Found-[*]:用户发出的请求针对的是不存在的记录
406 NOT Acceptable-[8]:用户请求格式不可得
410 Gone-[GET]:用户请求的资源被永久移除,且不会再得到
422 Unprocesable entiy-[POST/PUT/PATCH]:当创建一个对象时,发生一个验证错误
500 INTERNAL SERVER EROR-[*]:服务器内部发生错误
2.8 错误处理
如果状态码是4xx,就应该向用户返回出错误信息。一般来说,返回的信息中将error作为键名
2.9 返回结果
针对不同操作,服务器向用户返回的结果应该符合以下规范
GET /collection:返回资源对象的列表(数组、集合)
GET /collection/id:返回单个资源对象
POST /collection:返回新生成的资源对象
PUT /collection/id:返回完整的资源对象
PATCH /collection/id:返回完整的资源对象
DELETE /collection/id:返回一个空文档
图文详情: