RESTful个人看法

RESTful是现在公司较为常用的一种HTTP规范中URI规范，全称为Representational State Transfer，中文意思是表述性状态转移。

Representation表现层

所谓”资源“，就是网络上一个实体，或者说是网络上一个具体信息。而把”资源“具体呈现出来的形式，叫做它的"表现层"

StateTransfer状态转化

如果客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"。这种转化是建立在表现层上的，所以就是"表现层状态转化"。而客户端用到的手段只能是HTTP协议。

 

如果不懂URL和URI的区别，可以回顾我写的文章《URI和URL、URN的父子关系》

 

今天参考了网上很多的文章，很多内容，综合写出今天的这篇RESTful

论文地址：https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

REST章节地址：https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

(转自知乎https://www.zhihu.com/question/28557115/answer/48094438)

大神汇聚的Git(https://github.com/aisuhua/restful-api-design-references)

 

根据之前我写文章《HTTP请求方式》

得出最常用的四种请求方式

GET

特点

• 安全且幂等

• 获取表示

• 变更时获取表示(缓存)

PUT

特点

• 不安全且不幂等
• 使用服务端管理的(自动产生)的实例号创建资源
• 创建子资源
• 部分变更资源
• 没有被修改，则不过更新资源(乐观锁)

POST

特点

• 不安全但幂等
• 用客户端管理的实例号创建一个资源
• 通过替换的方式更新资源
• 如果未被修改，则更新资源

DELETE

特点

• 不安全但幂等
• 删除资源

安全：不会给服务器带来副作用

幂等：调用多少次都不会不同结果

RESTful架构常见问题

1. URI包含动词，资源是一种实体，应该使用名词。
2. 在URI中加入版本号，不同的版本号可以理解为同一种资源不同表现形式，所以应该采用同一个URI，可以在Accept字段中区分版本(很多的人说不放在URI，也有很多说放URI，个人觉得是不放的较好)

设计API满足RESTful

1. URL root
2. API versioning(要规范version的位置)
3. 使用名称而不是动词，建议使用复数
4. 保证HEAD和GET方法是安全的，不会对资源状态有所改变(或污染)
5. 资源地址推荐用嵌套结构

返回结果规范

1. GET /collection：返回资源对象的列表（数组）
2. GET /collection/resource：返回单个资源对象
3. POST /collection：返回新生成的资源对象
4. PUT /collection/resource：返回完整的资源对象
5. PATCH /collection/resource：返回完整的资源对象
6. DELETE /collection/resource：返回一个空文档

较好的RESTful模型

1. GET /zoos：列出所有动物园
2. POST /zoos：新建一个动物园
3. GET /zoos/ID：获取某个指定动物园的信息
4. PUT /zoos/ID：更新某个指定动物园的信息（提供该动物园的全部信息）
5. PATCH /zoos/ID：更新某个指定动物园的信息（提供该动物园的部分信息）
6. DELETE /zoos/ID：删除某个动物园
7. GET /zoos/ID/animals：列出某个指定动物园的所有动物
8. DELETE /zoos/ID/animals/ID：删除某个指定动物园的指定动物

以上为个人见解，有想法的朋友可以留言大家一起讨论