Restful到底是什么

最新推荐文章于 2024-04-07 08:48:29 发布

Jaymeng8848

最新推荐文章于 2024-04-07 08:48:29 发布

阅读量222

点赞数

分类专栏：开发文章标签： restful

原文链接：https://blog.csdn.net/qq_27026603/article/details/82012277?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522159592263419725211903020%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D&request_id=159592263419725211903020&biz_id=0&utm_med

版权

开发专栏收录该内容

9 篇文章 2 订阅

订阅专栏

概念

REST (representation state transfer)表述性状态转移。该架构主张服务端维护资源状态，客户端维护会话状态，消除服务端维护客户请求状态的开销，有利于服务器横向扩展和负载均衡。

REST使服务器处于无状态，及服务器仅仅管理资源的状态，会话的状态的需要客户端自己来维持。举个例子，比如我调用远程服务next操作（功能：当前书籍的下一章），这时服务器端必须存有我当前浏览信息，才能使得next操作返回预期的结果。服务器同时要为所有的用户维护这样的信息才能返回正确的下一章内容给相应的用户。
那么能不能我主动告诉服务器我在哪一章呢，这样不就可以使得服务器不必大规模维护这样信息？当前可以，这就是REST思想的核心，客户端这边告诉服务器期望的状态，服务器返回相应的状态即可。也就说服务器不关心具体的处理过程只关系最后的状态。所以上面的例子，客户端可以发送https://www.my.com/article/2，告诉服务器我期望第二页的内容。且慢！那如果客户端希望删除下一章的内容怎么办？按照REST架构风格，同样也是发送上述请求？那服务器如何知道客户端的具体操作意图来完成资源的状态转移呢？这就需要在请求头中添加约定的动作Code。接下来就重点讲解

URL定义
资源：互联网所有的事物都可以被抽象为资源
资源操作：使用POST、DELETE、PUT、GET，使用不同方法对资源进行操作。
分别对应添加、删除、修改、查询。

传统方式操作资源
http://127.0.0.1/item/queryUser.action?id=1 查询,GET
http://127.0.0.1/item/saveUser.action 新增,POST
http://127.0.0.1/item/updateUser.action 更新,POST
http://127.0.0.1/item/deleteUser.action?id=1 删除,GET或POST

请求方式
可以通过 GET、 POST、 PUT、 PATCH、 DELETE 等方式对服务端的资源进行操作。其中，GET 用于查询资源，POST 用于创建资源，PUT 用于更新服务端的资源的全部信息，PATCH 用于更新服务端的资源的部分信息，DELETE 用于删除服务端的资源。

这里使用“用户”的案例进行回顾通过 GET、 POST、 PUT、 PATCH、 DELETE 等方式对服务端的资源进行操作。

使用RESTful操作资源

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

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

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

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

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

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

之前的操作是没有问题的,大神认为是有问题的,有什么问题呢?你每次请求的接口或者地址,都在做描述,例如查询的时候用了queryUser,新增的时候用了saveUser ，修改的时候用了updateUser,其实完全没有这个必要,我使用了get请求,就是查询.使用post请求,就是新增的请求,PUT就是修改，delete就是删除，我的意图很明显,完全没有必要做描述,这就是为什么有了restful.

API设计风格基本规则
1.使用名词而不是动词
不要使用：

/getAllUsers
/createNewUser
/deleteAllUser

2.Get方法和查询参数不应该涉及状态改变
使用PUT, POST 和DELETE 方法而不是 GET 方法来改变状态，不要使用GET 进行状态改变:

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

/cars 而不是 /car
/users 而不是 /user
/products 而不是 /product
/settings 而部署 /setting

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

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

5.使用Http头声明序列化格式
在客户端和服务端，双方都要知道通讯的格式，格式在HTTP-Header中指定

Content-Type 定义请求格式
Accept 定义系列可接受的响应格式

6.为集合提供过滤排序选择和分页等功能
Filtering过滤:

使用唯一的查询参数进行过滤：

GET /cars?color=red 返回红色的cars
GET /cars?seats<=2 返回小于两座位的cars集合

Sorting排序:

允许针对多个字段排序

GET /cars?sort=-manufactorer,+model

这是返回根据生产者降序和模型升序排列的car集合

Field selection

移动端能够显示其中一些字段，它们其实不需要一个资源的所有字段，给API消费者一个选择字段的能力，这会降低网络流量，提高API可用性。

GET /cars?fields=manufacturer,model,id,color

Paging分页

使用 limit 和offset.实现分页，缺省limit=20 和offset=0；

GET /cars?offset=10&limit=5

为了将总数发给客户端，使用订制的HTTP头： X-Total-Count.

链接到下一页或上一页可以在HTTP头的link规定，遵循Link规定:

Link: https://blog.mwaysolutions.com/sample/api/v1/cars?offset=15&limit=5; rel=“next”,
https://blog.mwaysolutions.com/sample/api/v1/cars?offset=50&limit=3; rel=“last”,
https://blog.mwaysolutions.com/sample/api/v1/cars?offset=0&limit=5; rel=“first”,
https://blog.mwaysolutions.com/sample/api/v1/cars?offset=5&limit=5; rel=“prev”,

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

一般在Url后面使用?v

/blog/api/v1

8. 使用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开发者应该避免这种错误。

使用详细的错误包装错误：

{

“errors”: [

{

"userMessage": "Sorry, the requested resource does not exist",

"internalMessage": "No car found in the database",

"code": 34,

"more info": "http://dev.mwaysolutions.com/blog/api/v1/errors/12345"

}

]

}

9.允许覆盖http方法
一些代理只支持POST 和 GET方法，为了使用这些有限方法支持RESTful API，需要一种办法覆盖http原来的方法。

使用订制的HTTP头 X-HTTP-Method-Override 来覆盖POST 方法.