【今日话题】 讨论下HTTP Method(如GET,POST,PUT,DELETE)的使用经验和应用场景等 - 青衫隐_刘 1. 在REST中都有特定的含义, 我记得非REST中,PUT是用来向服务器推文件的 - twin 2. put 推新资源 delete删除资源 - @理鱼 3. Restful API中定义资源动作，部分框架中也是个路由入口 - 刘卫涛 4. 问: 推资源，删除资源会有哪些业务场景用到呢？ - 青衫隐_刘 回: 比如用户的收货地址是一种资源,创建一个地址是POST,更新地址,就是PUT,删除收货地址就是DELETE - twin 5. head方法，用于验证url的连通性，如果返回可以访问，则表示这个链接可用，如果返回错误，则需要用get方法再试 - 风之缘 6. 除了GET, POST, PUT, DELETE, 在restful约定里面还有patch. PATCH跟PUT在约定中都是更新资源的意思. 但是PUT是更新整个, PATCH是更新局部 - John__ 7. 嗯,rails在这方面就做得很好 http://guides.rubyonrails.org/routing.html#crud-verbs-and-actions - twin 8. 问: 比如用户的收货地址是一种资源,创建一个地址是POST,更新地址,就是PUT,删除收货地址就是DELETE 这种完全可以用post解决吧？- 青衫隐_刘 回: 对,其实POST就够了. 所以我觉得写业务,get和post搭配就很好了. 当你需要提供api给外部时,才考虑rest - twin 9. 我先抛个砖，我理解的restful就是把uri理解成一个资源集散地 通过http的method表示对这个资源的 curd 欢迎大家拍砖 - 汉族教父 10. 为什么不紧紧用 get post 是应为只用这两个不能更清晰的来表现对资源的操作。 当然你非要只用这两个当然可以。只不过不清晰，也不符合rest api的标准. 我用过不少三方 api 国内按照这个标准的没几家。 - @理鱼 11. 因为http method是有限的, 用了rest意味着你的部分业务得合并在一起, 对开发人员要求更高了 - twin 12. 我理解的restful不是一个标准，设计的时候不必完完全全按照它提供的方式去做，它只是提供了一种设计规范或者是核心思想，根据这个思想设计api，对调用者有更高的又好度，更清晰。设计时根据具体情景可以灵活变通 - 涵戈 13. 用有限的http method去取代无限的action, 这是一宗罪. 不兼容已有路由系统,又是一宗罪 例如games/1/edit, games/1/ranking. edit是一个action,而ranking是resource,如果不是定两条路由规则,是匹配不出来的. - twin 14. 目前用rest,往往意味着开发人员第一步工作是想url, 定路由, 而不是直接动手工作 - twin 15. post delete put get，就好比增删改查 - 茂升 16. 就好比是一种设计模式. 就像现在web架构 大部分都是mvc,但也有ddd - flea 17. 反过来,REST好处也很多,强调了以resource为中心. 例如控制器经常会加入一些无关的action,就是因为开发人员没有以resource为中心 - twin 18. http method 的好处在于, 可以映射为读写删三种权限, 而get,post只是两种(结合destroy action可以加上删,但是没有http method直观) - twin 19. 现在移动互联网很火， 移动端平台又会越来越多， 对服务端来说统一api接口给不同平台调用， 这需要使用restful的架构思想来做 - Meow 20. REST是趋势,但已有系统大多是controller/action形式,我们也是,所以我们准备加上REST的支持,又保留已有系统的优势. 分享方案雏形给大家 a. 控制器和rails等一样,保留controller/action的形式, create对应post,destroy对应delete等等. 不使用resource::method形式,(如posts::get, post::delete),两个方面原因,一个是改造成本,另一个是resource::method扩展性差 b. request method判断逻辑改造,原来可能只判断request method是否为post,现在要细分为put,patch,delete. 这一步也可以跳过,以后再做.因为只有新的REST调用才关注method c. 路由器改造,也是最重要的一部分. 已有框架象rails, laravel都是写一个模块在路由器里定个resource或是写个route规则, 模块中的资源嵌套又得定一个resource. 这种方法不够敏捷,特别是当你有几十个,上百个资源. 因此,我们希望用一条正则,或是一个简单处理类解决所有REST路由问题. 传统的路由框架,一般是通过正则匹配出controller和action的.对于REST URL,如photos/1/comments和photos/1/edit. 通过正则匹配,要么认为comments和edit都是controller,要么认为comments和edit都是action,而实际comments是controller, edit是action. 因此,传统路由无法用一条正则解决所有REST url,我们需要写个路由处理类. 核心逻辑是,给定一个URL如 photos/1/comments, 根据数字和斜杠解析为 photos::comments?id=1 (controller::action?querystring)和comments::index?photoId=1两种情况. d. controller分发服务改造. 上面提到路由解析出来是两个controller和action. 传统mvc框架应该也是只支持一个controller::action的,所以要稍作改造,顺序判断哪个存在就执行哪个. 总结一下,保持控制器不变; 改造route解析出多组controller::action; controller分发服务支持多组controller::action 这样子就可以既保留原有业务,又享受REST的优雅. - twin 21. rest不只是一种协议 么. 这个与mvc不冲突啊 - tywei 回: rest不是协议，只是一种架构 - 光阴的故事 22. twin是主要把rest的http方法的约定去掉，保留url对不对 - 轩脉刃 回: 方法约束还是要的,有了才是rest,而且刚好可以拿来做权限控制. 但是原有系统改造这一步可以晚点做, 因为不影响原来的逻辑 - twin 23. 原来laravel的路由是基于symfony的路由..自己实现了很多对开发人员友好的方法,象Route::xx - twin 24. Laravel的路由还是蛮不错的，可根据资源例如user，直接定义基于user的RESTfull资源，Route::resource("user"，"UserController") - 青衫隐_刘 【分享链接】 1. 之前看谢大分享了这本电子书《Web API Design》，挺不错的，截图也来自这书 原地址：http://apigee.com/about/resources/ebooks/web-api-design 谢大搬到国内的地址：http://vdisk.weibo.com/lc/r07h62jt3F4PDsDPH 密码：HG7K - XiangZ 本文转载自：微信公众账号 - 黑夜路人技术，版权归原作者所有！ |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
