RESTful API
-
产生背景
- 前后端分离后,前端调用指定API获取到后端的数据,再展示出来,而随着前端设备的多样性(手机,平板,桌面电脑,其他专用设备等等),需要一种统一的机制,方便前后端通信,所以RESTful就是这样一种API设计理念,可以通过一套统一的接口为web,ios等提供服务。
-
REST
- REST 即:Representational State Transfer的缩写,“表现层状态转化”。
- 理解:
- 1.url定位资源
- 2.客户端和服务端之间传递这种资源的表现层
- 3.客户端通过HTTP动词(get,post,delete,put,patch)对服务端资源进行操作,实现变现层状态转化
-
RESTful 六大原则
-
C-S架构
- 数据存储在Server端,Client端只需要使用。前后端分离使得Client端的代码可移植性增强,Server端扩展性增强,两端单独开发,互相不干扰。
-
无状态
- http请求本身就是无状态的,基于C-S架构,客户端每一次请求都要带着充分的信息让服务端识别。服务端根据请求的参数,无需保存客户端的状态,将响应正确的返回给客户端,大大提高了效率和性能。
- 缺点就是客户端的每一次请求都需要带上相同重复的信息表明自己的身份和状态,会造成传输的冗杂,但这些对于性能和使用来说,可以忽略不计。
-
统一的接口
- REST架构的核心内容,统一的接口对于RESTful服务来说非常必要,前端只需要关注接口,接口的可读性增加,使用人员方便调用
- REST接口约束为:
- 资源识别:通过url标识你要操作的资源
- 请求动作:通过请求动作(post,put,get等)标识执行的操作
- 响应信息:通过返回的状态码来表示这次请求的执行结果
-
一致的数据格式
服务端返回的数据要么是XML,要么是json,要么是状态码
比如请求一条微博信息,服务端响应信息应该包含这个微博相关的其他URL,客户端就可以进一步利用这些URL发起请求获取感兴趣的信息,就像分页,第一页里可以获取下一页的URL就是这个原理
下面以返回数据json格式为例简单讲一下数据格式
-
返回数据通常含有一些字段:
code-----HTTP响应状态码,status------包含文本“success”(其他) |'fail ‘ (状态码5××) |'error'(状态码4××)message-----状态值为’fail‘和’error‘时生效,显示错误信息data-----包含响应的数据,状态值为fail或者error,data仅包含错误原因或者异常名称或者null也可以。比如下面就是一个响应成功的json格式
{ "code": 200, "message": "success", "data": { "userName": "123456", "age": 16, "address": "beijing" } }
-
可缓存
- 在万维网上,客户端是可以缓存页面的响应内容,因此响应都应该显式或隐示的定义为可缓存,如果不可以缓存也要避免客户端拿旧数据或者脏数据来响应,缓存得当可以减少客户端和服务端的交互,进一步的优化性能。
-
按需编码,可定制代码
- 服务端可选择临时给客户端下发一些功能代码让客户端来执行,从而定制和扩展客户端的某些功能。比如服务端可以返回一些 Javascript 代码让客户端执行,去实现某些特定的功能。提示:REST架构中的设计准则中,只有按需编码为可选项。如果某个服务违反了其他任意一项准则,严格意思上不能称之为RESTful风格。
-
-
HTTP动词
- GET:从服务器取出资源
- POST:在服务器新建一个资源
- PUT: 在服务器更新资源(客户端提供改变后的完整资源)
- PATCH:在服务器更新资源(客户端提供改变的属性)
- DELETE:从服务器删除资源
-
HTTP状态码
- 1××:不常用,表示请求未成功
- 2××:成功
- 3××:重定向,原有文件永久搬走或者临时出走
- 4××: 客户端的请求可能出错了
- 5××: 服务端内部出错了