为什么要用restful风格

为什么要使用restful风格请求：

那么在前端和后端之间就必然存在着通信，因此API架构诞生了。目前RESTful API是目前比较成熟的一套互联网应用程序的API设计理论。

RESTful是一种设计风格，并非一个标准。因此，即使完全不用这种风格，功能上也能够满足需求。
但是它结构清晰、符合标准、易于理解、扩展方便，越来越多网站在采用它，建议你也去了解一下。

URI(Uniform Resource Identifier),统一资源标志符,只代表资源的实体

URL(Universal Resource Locator),统一资源定位符。

HTTP协议里面，有四个表示操作方式的动词：GET、POST、PUT、DELETE。它们分别对应四种基本操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。
当然你完全可以一个POST走天下，功能实现上完全没有问题，但是这样不符合RESTful设计风格。

URI不应该有动词，动词应该放在HTTP协议中。
另一个设计误区，就是在URI中加入版本号。因为不同的版本，可以理解成同一种资源的不同表现形式，所以应该采用同一个URI。

使用RESTful操作资源

【GET】 /users # 查询用户信息列表

【GET】 /users/1001 # 查看某个用户信息

【POST】 /users # 新建用户信息

【PUT】 /users/1001 # 更新用户信息(全部字段)

【PATCH】 /users/1001 # 更新用户信息(部分字段)

【DELETE】 /users/1001 # 删除用户信息

restful风格API使用规则

• 使用名词而不是动词

不要使用：

/getAllXX

/createNewXXX

/deleteAllXX

Get方法和查询参数不应该涉及状态改变

使用PUT, POST 和DELETE 方法 而不是 GET 方法来改变状态，不要使用GET 进行状态改变:

接口注解使用如下：

---

 

• 使用复数名词

不要混淆名词单数和复数，为了保持简单，只对所有资源使用复数。

/cars 而不是 /car

/users 而不是 /user

/products 而不是 /product

/settings 而部署 /setting

---

• 使用子资源表达关系

如果一个资源与另外一个资源有关系，使用子资源：

GET /cars/711/drivers/ 返回 car 711的所有司机

GET /cars/711/drivers/4 返回 car 711的4号司机

---

• 使用Http头声明序列化格式

在客户端和服务端，双方都要知道通讯的格式，格式在HTTP-Header中指定

Content-Type 定义请求格式

Accept 定义系列可接受的响应格式

---

• 版本化你的API

使得API版本变得强制性，不要发布无版本的API，使用简单数字，避免小数点如2.5.

一般在Url后面使用?v

/blog/api/v1

---

• 使用Http状态码处理错误

如果你的API没有错误处理是很难的，只是返回500和出错堆栈不一定有用

Http状态码提供70个出错，我们只要使用10个左右：

200 – OK – 一切正常

201 – OK – 新的资源已经成功创建

204 – OK – 资源已经成功擅长

304 – Not Modified – 客户端使用缓存数据

400 – Bad Request – 请求无效，需要附加细节解释如 "JSON无效"

401 – Unauthorized – 请求需要用户验证

403 – Forbidden – 服务器已经理解了请求，但是拒绝服务或这种请求的访问是不允许的。

404 – Not found – 没有发现该资源

422 – Unprocessable Entity – 只有服务器不能处理实体时使用，比如图像不能被格式化，或者重要字段丢失。

500 – Internal Server Error – API开发者应该避免这种错误。

---

• 协议

API与用户的通信协议，总是使用HTTPs协议。