[历史归档]本文原发布于 cstriker1407.info 个人博客内容为历史存档仅供参考。发布时间2018-07-24 标题[转]REST以及RESTful的讲解分类编程 标签restfulRESTful简单笔记本文转自《 https://blog.csdn.net/qq_21383435/article/details/80032375 》有较大删改规则GET 用来获取资源POST 用来新建资源也可以用于更新资源PUT 用来更新资源DELETE 用来删除资源例子DELETE http://api.qc.com/v1/friends: 删除某人的好友 在http parameter指定好友idPOST http://api.qc.com/v1/friends: 添加好友UPDATEhttp://api.qc.com/v1/profile: 更新个人资料概念REST 是面向资源的这个概念非常重要而资源是通过 URI 进行暴露。URI 的设计只要负责把资源通过合理方式暴露出来就可以了。对资源的操作与它无关操作是通过 HTTP动词来体现所以REST 通过 URI 暴露资源时会强调不要在 URI 中出现动词。比如左边是错误的设计而右边是正确的GET /rest/api/getDogs -- GET /rest/api/dogs 获取所有小狗狗GET /rest/api/addDogs -- POST /rest/api/dogs 添加一个小狗狗GET /rest/api/editDogs/:dog_id -- PUT /rest/api/dogs/:dog_id 修改一个小狗狗GET /rest/api/deleteDogs/:dog_id -- DELETE /rest/api/dogs/:dog_id 删除一个小狗狗REST很好地利用了HTTP本身就有的一些特征如HTTP动词、HTTP状态码、HTTP报头等等REST API 是基于 HTTP的所以你的API应该去使用 HTTP的一些标准。这样所有的HTTP客户端如浏览器才能够直接理解你的API当然还有其他好处如利于缓存等等。REST 实际上也非常强调应该利用好 HTTP本来就有的特征而不是只把 HTTP当成一个传输层这么简单了。REST 系统的特征客户-服务器Client-Server提供服务的服务器和使用服务的客户需要被隔离对待。无状态Stateless来自客户的每一个请求必须包含服务器处理该请求所需的所有信息。换句话说服务器端不能存储来自某个客户的某个请求中的信息并在该客户的其他请求中使用。可缓存Cachable服务器必须让客户知道请求是否可以被缓存。Ross更详细解释请参考 理解本真的REST架构风格 以及 StackOverflow 的这个问题 中对缓存的解释。分层系统Layered System服务器和客户之间的通信必须被这样标准化允许服务器和客户之间的中间层Ross代理网关等可以代替服务器对客户的请求进行回应而且这些对客户来说不需要特别支持。统一接口Uniform Interface客户和服务器之间通信的方法必须是统一化的。RossGET,POST,PUT.DELETE, etc支持按需代码Code-On-Demand可选服务器可以提供一些代码或者脚本RossJavascrptflashetc并在客户的运行环境中执行。这条准则是这些准则中唯一不必必须满足的一条。Ross比如客户可以在客户端下载脚本生成密码访问服务器。详细解释无状态Stateless所谓无状态的即所有的资源都可以通过URI定位而且这个定位与其他资源无关也不会因为其他资源的变化而改变。有状态和无状态的区别举个简单的例子说明一下。如查询员工的工资如果查询工资是需要登录系统进入查询工资的页面执行相关操作后获取工资的多少则这种情况是有状态的因为查询工资的每一步操作都依赖于前一步操作只要前置操作不成功后续操作就无法执行如果输入一个url即可得到指定员工的工资则这种情况是无状态的因为获取工资不依赖于其他资源或状态且这种情况下员工工资是一个资源由一个url与之对应可以通过HTTP中的GET方法得到资源这是典型的RESTful风格。统一接口Uniform InterfaceRESTful架构风格规定数据的元操作即CRUD(create, read, update和delete,即数据的增删查改)操作分别对应于HTTP方法GET用来获取资源POST用来新建资源也可以用于更新资源PUT用来更新资源DELETE用来删除资源这样就统一了数据操作的接口仅通过HTTP方法就可以完成对数据的所有增删查改工作。即GETSELECT从服务器取出资源一项或多项。POSTCREATE在服务器新建一个资源。PUTUPDATE在服务器更新资源客户端提供完整资源数据。PATCHUPDATE在服务器更新资源客户端提供需要修改的资源数据。DELETEDELETE从服务器删除资源。演化https://zhuanlan.zhihu.com/p/30396391?group_id937244108725641216优点缺点优点是因为他对uri进行了限制只用于定义资源。这样看起来比较容易理解。尤其是对简单的对象的增删改查很好理解。缺点是因为这种限制导致设计uri变得复杂了。尤其是复杂的关系操作资源集合硬性套用rest原则设计非常困难。在rest基础上的HATEOAS返回的json里增加了相应的关系和url。这也同样带来问题。好处是对简单的关系的确可以通过url进一步处理。但对复杂的关系和操作HATEOAS并不能胜任描述。反而在单纯的数据中增加了一堆垃圾信息。REST是什么REST是一个标准一种规范遵循REST风格可以使开发的接口通用便于调用者理解接口的作用。参考https://www.zhihu.com/question/28557115https://blog.igevin.info/posts/restful-architecture-in-general/