Rest/RestFul的理解(一家之见)

--------------------------------------------------如果你不学习，那么你的知识每18个月贬值一半，这就是软件行业的摩尔定律。

Rest:是一种基于HTTP协议之上的一种API设计的风格不是规范(是一组没有严格标准的架构约束条件和设计原则)，使得懂得HTTP协议的开发者，尽可能不需要过多的交流达到“理解”接口的目的。

理解概念：

资源：

        网络上的所有事物都可以被抽象为资源(resource)。

        每一个资源都有唯一的资源标识(URI)，对资源的操作不会改变这些标识。

                   在Server端中的应用程序状态和功能都可以抽象为一种资源，如：应用程序对象、数据库记录、算法等，这些资源以URI(Universal Resource Identifier)的方式向Client公开。每一个资源映射到一个URI，URI作为资源的唯一标识。

URI: 统一资源标识符(URI：一类资源)。

URL: 统一资源定位符(URL：URI+LOACATE)。

URI和URL的关系：URL是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何Find这个资源。

状态转移: URI的命名要使用名词，那我们要如何来表示一个操作动作呢？就是依靠HTTP方法，也叫HTTP动词。也就是通过这种动名词的组合来表示一次操作，在REST中会被叫做状态转移

某个API: API：(URI+URL+URI操作类型+API返回状态+API参数+API返回值)。

设计一个API需要考虑的因素：

URI、URL、URI操作类型、API参数、API返回状态、API返回值。

为达到目的需要考虑API满足因素：

自解释性、无状态、是否简单。

1、自解释性？

A、针对URI操作类型：将HTTP中的方法CRUD和接口方法CRUD对应起来。因为所有复杂的业务无非就是CRUD组合而成。

POST：新增资源

DELETE：删除资源

PUT：修改资源

GET：获取资源

严格遵守存在的问题：复杂需求中国GET参数过长时不满足,如批量删除，批量查询。

B、针对API返回状态：将HTTP中的状态码和HTTP协议中的状态码对应起来。

2xx：请求正常处理并返回。

3xx: 重定向，请求资源位置发生了变化。

4xx: 客户端发送的请求有误。

5xx: 服务器端错误。

C、针对URI：

             见名知意

只能使用名词，推荐使用复数(无状态性)。

统一使用小写字母。

不要包含文件（脚本）的扩展名。

URI中尽量使用连字符"-"代替下划线"_"的使用。

"_"一般用于对一个整体含义的字符串做了层级的分割。

REST API URI的七大设计原则

规则1：URI结尾不应包含（/）

规则2：正斜杠分隔符（/）必须用来指示层级关系

规则3：应使用连字符（ - ）来提高URI的可读性

规则4：不得在URI中使用下划线（_）

规则5：URI路径中首选小写字母

规则6：文件扩展名不应包含在URI中

规则7：所用的名词往往与数据库的表格名对应

D、针对URL

     尽可能采用HTTPS协议。

2、是否简单

A、针对返回值类型

     采用JSON格式的返回值

 

3、无状态

A、针对API请求参数

        每一个API请求参数必须包含服务器端理解请求的全部参数。

        例如：在写API认证的时候将sessionid返回给前端，之后每次带上sessionid的模式是unrestfull模式，因为只要服务器端保存了状态。

详解：有状态和无状态与请求本身没有多大关联，重要的是状态信息是由请求方还是响应方负责保存。在Session ID可以被认为是一个用来标识某一会话状态的Key，将其传递给服务器端意味着这样一个请求：“请帮我取出这个状态信息”，也就是说这个请求假设响应方保有着状态信息。由于与某一特定请求相关的状态属于应用状态，而RESTful架构要求任何此类状态由请求方负责提供，所以传递Session ID被认为是unRESTful的做法。反过来，user credential作为一种应用状态，是被期望由请求方提供的，所以在请求中传递user credentials（姑且忽略安全性问题）是符合RESTful架构规范的。

应该这么做呢（本质不依赖某一系统或者缓存，状态）？

可以在登陆之后利用登录名和密码生成相应的token，将token返回给前端，每次请求时将token发送给后端，后端进行解析得到用户名和密码，进行相应的认证，也可以在生成token之后将其存储于缓存中，请求过来后直接读取token，匹配token，如果token匹配不成功则可以进行解析得到用户名和密码，查询持久化数据库进行认证。

        安全性、幂等性

https://blog.csdn.net/u013731455/article/details/56278168

 

设计经验

GET /users - 获取用户列表

GET /users/1 - 获取 Id 为 1 的用户

POST /users - 创建一个用户

PUT /users/1 - 替换 Id 为 1 的用户

PATCH /users/1 - 修改 Id 为 1 的用户

DELETE /users/1 - 删除 Id 为 1 的用户

GET /users/1/products - 获取 Id 为 1 用户下的产品列表

GET /users/1/products/2 - 获取 Id 为 1 用户下 Id 为 2 的产品

POST /users/1/products - 在 Id 为 1 用户下，创建一个产品

PUT /users/1/products/2 - 在 Id 为 1 用户下，替换 Id 为 2 的产品

PATCH /users/1/products/2 - 修改 Id 为 1 的用户下 Id 为 2 的产品

DELETE /users/1/products/2 - 删除 Id 为 1 的用户下 Id 为 2 的产品

"current_user_repositories_url": https://api.github.com/user/repos{?type,page,per_page,sort} -获取某一用户下，分页查询的网摘列表

充满Rest风格的架构称为RestFul架构的项目。