REST基本概念

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
• 鉴权 确定用户是否有权利
• 限流 限制访问、请求