restFul的优缺点以及思考

常用经验

• 在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 规范。