常用经验
-
在HTTP中,我们要通过 URL 进行资源的定位
比如:
要取 id=888 的用户信息,我们就向/user/{id} 这个路径发送请求,
要取 id=888 的用户的订单列表,我们就向/user/{id}/orders 这个路径发送请求
-
在HTTP 中,DELETE、PUT、GET请求应该是幂等的,而POST 则不是幂等的。所谓“幂等”指的是:对于一个接口采用同样的参数请求一次和请求多次的结果是一致的,不会因为多次请求而产生副作用
-
在HTTP中,GET请求的响应是可以被缓存的,而DELETE、PUT、POST请求的响应是不可以被缓存的。客户端、网关等可以根据情况对 GET 请求的响应进行缓存,从而提升性能
-
在HTTP中,服务器端要通过状态码来反映资源获取的结果
比如:
客户端要获取id-8的用户,如果要获取的用户不存在,则服务器返回的状态码为 404,而如果当前客户端没有权限获取这个用户,服务器返回的状态码为 403。再如,对于新增用户请求,如果新增成功,服务器返回的状态码为 201
优点
-
所有的资源都尽量通过URL来表示,URL的语义性更清晰
-
对所有类型资源的新增、删除、修改、查询操作都统一为向资源发送POST、DELETE.、PUT、GET 请求,接口统一且具有自描述性,减少了开发人员对接口文档的依赖性
-
对于 GET、PUT、DELETE 等幂等的操作,网关、网络请求组件等可以对失败的请求自动重试
-
网关等可以对 GET 请求进行缓存,能够提升系统的访问速度,而且降低服务器的压力
-
通过HTTP状态码反映服务器端的处理结果,能够统一错误码,避免自定义错误码带来的不统一的问题
户端也可以根据错误码进行统一处理,比如对于 403 状态码,客户端统一提示用户去登录
-
网关等系统可以根据状态码来分析系统的访问数据,比如可以根据 HTTP状态码分析有多少成功的请求,有多少失败的请求
缺点
- 真实系统中的资源非常复杂,很难清晰地进行资源的划分
- 真实系统中的业务很复杂,并不是所有的操作都能简单地对应到PUT、GET、DELETE、POST上
- 真实系统是在不断进化的,一个操作最开始的时候被设计为幂等的 PUT,但是后来的版本又修改了逻辑,可能该操作就变成了不幂等的。如果调用者继续对这个操作进行重试可能会有副作用
- 在 Restful 中,资源尽量通过 URL来定位,要尽量避免使用 QueryString 及请求报文体传递数据
- HTTP状态码的个数是有限的,特别是用于表示业务相关的错误码主要在 4xx状态码段中,而业务系统中的错误非常复杂,仅通过 HTTP状态码来反映错误有时候会无法满足要求
- 有的客户端是不支持 PUT、DELETE 请求的。例如: 旧版本的程序
总结
REST 概念是用来指导我们设计接口的,而不是给开发带来麻烦的,它只是一个参考的风格,并不是一个必须遵守的规范,不能因为要遵守Restful 风格而影响开发进度及系统的稳定。项目开发的时候,需要根据项目特点、公司人员等多方面情况,确定一个符合项目情况的定制版 Restful 规范。
标签:状态,HTTP,请求,GET,优缺点,思考,PUT,restFul,DELETE From: https://www.cnblogs.com/zwhdd/p/17669881.html