REST(Representational State Transfer)
GitHub上的REST API是相当标准REST风格
Representational :数据的表现形式(JSON,XML…),rest对数据不做任何限制,但是用的最多的是json
State:当前状态或者数据
Transfer:数据传输
是万维网软件架构风格 不是什么硬性规范
用来创建万维网网络服务的
REST的六个限制 规范
客户-服务器(Client-Server)
-
服务端专制数据存储,提升了简单性
-
前端专注用户界面,提升了可移植性
无状态(Stateless)
-
所有用户会话信息都保存在客户端
-
每次请求必须包括所有信息,不能依赖上下文信息(比如页数信息,只能告诉服务器要去第几页,而不能只告诉服务器进入下一页,因为服务器不知道当前为第几页)就是一种无状态
-
服务器不用保存会话信息,提升了简单性、可靠性(因为每次都是全部的信息,不需要根据上下文)、可见性
缓存(Cache)
- 所有服务器响应都要被标为可缓存或不可缓存
- 减少前后端交互,提升效率和性能
统一接口(Uniform Interface)
- 接口设计尽可能统一通用,提升了简单性和可见性
- 接口与实现解耦,使前后端可以独立开发
分层系统(Layered System)
- 每层只知道相邻的一层,后面隐藏的就不知道了
- 客户端不知道是和代理还是真实服务器通信
- 其他层:安全层、负载均衡、缓存层等
按需代码(Code-On-Demand可选)
- 客户端可以下载运行服务端传来的代码
统一接口限制
资源的标识
- 资源是任何可以命名的事物,比如用户、评论等
- 每个资源可以通过URI被唯一地标识
- 比如:https://api.github.com/users
通过表述来操作资源
- 表述就是Representational(比如json)
- 客户端不能直接操作服务器资源,比如数据库,要通过Representational(比如json)来操作
自描述消息
- 每个消息(请求或者响应)必须提供足够的信息让接受者理解
- 媒体类型(application/json、application/xml)
- HTTP方法:get(查)、post(增)、delete(删)、put(基本为整体更新)、patch(部分更新)
- 是否缓存:Cache-Control 一般是请求头中的
超媒体作为应用状态引擎
- 超媒体:带文字的连接
- 应用状态:一个网页
- 引擎:驱动、跳转
- 就是一个 点击链接跳转到另一个页面
RESTful API
符合REST风格的API
要包含
- 基本的URI,如:https://api.github.com/users
- 标准HTTP方法:比如get、post、delete、put
- 传输数据每天类型:比如JSON,XML
DELETE /repos/octocat/hello-world/issues/comments/42
请求规范
- URI使用名词,尽量使用复数 /users
- URI使用嵌套表示关联关系, /users/12/repos/5
GET /repos/octocat/hello-world/issues/42/comments
- 使用符合请求意思的HTTP方法
- 不符合增删改查的情况:
- POST+动词
- 在查询字符串中加入action=value
- 设计为子资源
响应规范
- 查询 比如:https://api.github.com/users?since=100
- 分页 比如:https://api.github.com/user/repos?page=2&per_page=100
- 字段过滤 比如:https://api.github.com/users/xasasd?fileds=name
- 状态码
- 错误处理 状态码+message
安全
- HTTPS
- 鉴权 确定用户是否有权利
- 限流 限制访问、请求