RESTful API增删改查分别使用的 HTTP 方法(verb) 和 返回码

RESTFul API 特点

URL定位资源，用HTTP动词（GET,POST,DELETE,DETC）描述操作。

• 基于“资源”，数据也好、服务也好，在RESTFul设计里一切都是资源。
• 无状态。一次调用一般就会返回结果，不存在类似于“打开连接-访问数据-关闭连接”这种依赖于上一次调用的情况。
• URL中通常不出现动词，只有名词
• URL语义清晰、明确
• 使用HTTP的GET、POST、DELETE、PUT来表示对于资源的增删改查
• 使用JSON不使用XML
  我举个例子：
  网站：/get_user？id=3
  RESTFul:GET /user/3 (GET是HTTP类型)

GET 用来获取资源，
POST 用来新建资源（也可以用于更新资源）
PUT 用来更新资源，
DELETE 用来删除资源。

可能会说，GET、POST也经常用啊。但是在网站里的GET和POST同RESTFul中的GET、POST是不一样的。网站里使用GET、POST的选择点在于，简单的用GET、复杂对象用POST；但在REST里，GET对应的是查询一个资源，而POST对应的是新增一个资源，意义是决然不同的。理解这一点非常重要。

接着来看一看RESTFul API的一些最佳实践原则：

1. 使用HTTP动词表示增删改查资源， GET：查询，POST：新增，PUT：更新，DELETE：删除
2. URI使用名词而不是动词，且推荐使用复数
3. 保证HEAD和GET方法是安全的，不会对资源状态有所改变（污染）。比如：严格杜绝如下情况：GET/deleteProduct？id=1
4. 资源的地址推荐用嵌套结构。比如：GET/friends/10375923/profile
5. 警惕返回结果的大小。如果过大，及时进行分页（pagination）或者加入限制（limit）。HTTP协议支持分页（Pagination）操作，在Header中使用Link即可。
6. 使用正确的HTTP Status Code 表示访问状态。
7. 返回结果必须使用JSON
8. HTTP状态码，在REST中都有特定的意义：200，201,202,204,400,401,403,500。比如401表示用户身份认证失败，403表示你验证身份通过了，但这个资源你不能操作。
9. 如果出现错误，返回一个错误码。

 1. API必须有版本的概念，v1，v2，v3 
 2. 使用Token令牌来做用户身份的校验与权限分级，而不是Cookie。
 3. url中大小写不敏感，不要出现大写字母 
 4. 使用 - 而不是使用 _ 做URL路径中字符串连接。 
 5. 有一份漂亮的文档~（很重要）

1.rest协议是面向资源的，而资源是通过URI进行暴露

URI 的设计只要负责把资源通过合理方式暴露出来就可以了。对资源的操作与它无关，操作是通过 HTTP动词来体现，所以REST 通过 URI 暴露资源时，会强调不要在 URI 中出现动词。

假如要管理一些用户，那么将用户看作是一种资源：

get /users/{userId}  获取userId对应的user信息
post /users 创建一个新的user
put /users/{userId} 更改userId对应的user信息
delete /users/{userId} 删除userId对应的user。

2、REST很好地利用了HTTP本身就有的一些特征，如HTTP动词、HTTP状态码、HTTP报头等等

HTTP动词

GET     获取一个资源 
POST    添加一个资源 
PUT     修改一个资源 
DELETE  删除一个资源

实际上，这四个动词实际上就对应着增删改查四个操作，这就利用了HTTP动词来表示对资源的操作。
HTTP状态码

200 OK 
400 Bad Request 
500 Internal Server Error

在 APP 与 API 的交互当中，其结果无非就三种状态：

所有事情都按预期正确执行完毕 - 成功
APP 发生了一些错误 – 客户端错误
API 发生了一些错误 – 服务器端错误

这三种状态与上面的状态码是一一对应的。

HTTP报头

Authorization 认证报头 
Cache-Control 缓存报头 
Cnotent-Type  消息体类型报头 

…报头还有很多，不一一列举。HTTP报头是描述HTTP请求或响应的元数据，它的作用是客户端 与 服务器端进行相互通信时，告诉对方应该如何处理本次请求。

---

https://zhuanlan.zhihu.com/p/30396391?group_id=937244108725641216

---

https://blog.csdn.net/chenxiaochan/article/details/73716617

---

https://blog.csdn.net/chenxiaochan/article/details/73716617