【笔记向】RESTful api
RESTful api 是什么
Representational state transfer:
Representational：数据表现形式
state：状态
transfer：数据传输
REST精髓：6个限制
1.Client-Server
关注点分离
服务端专注数据存储，提高简单性
前端专注用户界面，提高可移植性
2.无状态
所有用户会话信息保存在客户端
每次请求必须包括所有信息，不能依赖上下文信息
服务端不用保存会话信息，提高了简单性，可靠性，可见性
（如果后端存用户会话信息，从故障中恢复几乎不可能）
（可见性：所有的信息是传参过去的，而不是隐藏的状态，所有的信息都可以控制）
3.缓存
所有服务端响应，都要被标记为可缓存和不可缓存（静态文件可以缓存）
缓存减少前后端交互，提高性能
4.统一接口
统一接口突出了 REST 的特点
接口设计尽可能统一，提升了简单性，可见性
所有的接口遵循同一个规范，所以交互的可见性高（看到接口就知道是干嘛的）
5.分层系统
每层只知道相邻的层
比如加了一层代理，阿里有中间件系统，比如安全层，负载均衡，缓存层
6.按需代码（非必选）
客户端可以下载运行服务端传来的代码
简化客户端，提升客户端简单性
统一接口的主要内容
资源的标识
资源是可以命名的事物，评论、用户（都是名词）
每个资源可以被 uri 唯一的标识
通过表述来操作资源
客户端不能直接操作资源，只能通过 representation （就是json、xml）
自描述信息
每个消息（请求响应）必须提供足够的信息
例如媒体类型，http方法
是否缓存
超媒体作为应用状态引擎
超媒体的含义就是，api（即url）里面不仅仅存数据，而是一个超媒体用来代表下一个动作（即应用状态），例如
{
// 非超媒体
nsid:'18345671234@bzzb'
}
{
// 超媒体
nsid:"http://api.fl.com/services/rest/?method=flickr.people.getInfo?auth_key=xxxx&user_id=18345671234@bzzb"
}
RESTful API 简介
1.基础的uri
2.标准http请求（get post patch delete 等）
3.媒体类型，json xml
举例 github repos api
其中增加删除修改都很常规，但是有个转移api，transfer，他是这样设计的（注意REST中限制了uri只能用名词，但是http自带的那些动词无法完全描述api的行为时，就可以像GitHub这样）
POST /repos/{owner}/{repo}/transfer
设计请求规范
URI 使用名词，尽量用复数，如
/users
使用嵌套来标识关联关系，如/user12/repos/5
使用正确的http方法：get/post/put/delete
不符合的情况：POST + 动词/actioin（uri的查询字符串中指明）/子资源
响应设计规范
查询，每个响应都可以被查询（被过滤）
分页，（本质也是查询）
过滤字段，（只返回指定的字段）
状态码
错误处理
安全
https
鉴权（基础鉴权，OAuth鉴权）
限流（请求头里有字段）
开发者友好
文档
超媒体（像导航一行的url列表）
