V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
ikaiguang
V2EX  ›  服务器

如何看待:不遵循 restful_api 设计,所有的 api 使用 POST 提交

  •  3
     
  •   ikaiguang · 2019-08-26 14:26:34 +08:00 · 8402 次点击
    这是一个创建于 1677 天前的主题,其中的信息可能已经有所发展或是发生改变。
    • GET ( SELECT ):从服务器取出资源(一项或多项)。
    • POST ( CREATE ):在服务器新建一个资源。
    • PUT ( UPDATE ):在服务器更新资源(客户端提供改变后的完整资源)。
    • PATCH ( UPDATE ):在服务器更新资源(客户端提供改变的属性)。
    • DELETE ( DELETE ):从服务器删除资源。

    把所有的 API 都设计为 POST 提交方式,你们是如何看待的。

    懒?

    38 条回复    2019-08-27 17:23:30 +08:00
    ieiayaobb
        1
    ieiayaobb  
       2019-08-26 14:37:22 +08:00
    当 GET 超过了 URL 限制,只能用 POST 替代
    qq292382270
        2
    qq292382270  
       2019-08-26 14:43:29 +08:00
    我觉得挺好的. 因为我的客户大部分只会 post .
    mokeyjay
        3
    mokeyjay  
       2019-08-26 14:48:46 +08:00
    没啥好看待的,有些人只知道获取资源用 GET,其他所有情况用 POST
    至于用这种还是用 restful 看具体情况谁话语权大了
    Cyron
        4
    Cyron  
       2019-08-26 14:50:37 +08:00
    无所谓,文档写好就行了
    wingoo
        5
    wingoo  
       2019-08-26 14:52:24 +08:00   ❤️ 1
    restful 并不是标准, 不用就会出错
    hnbcinfo
        6
    hnbcinfo  
       2019-08-26 14:53:20 +08:00
    严格遵循 restful 我觉得不现实,也不一定就好。我一般就用 Get Post。读操作 get,写操作 post,当然也会偶尔有例外。只要文档写好,有一套规则,别随便用就好。
    rockyou12
        7
    rockyou12  
       2019-08-26 14:55:32 +08:00   ❤️ 1
    远古时代,http 的 get 请求会被各种服务商做缓存,所以请求都用 post 还算合理的设计。现在反正都 https 了,不存在了
    mcfog
        8
    mcfog  
       2019-08-26 15:02:51 +08:00   ❤️ 1
    不如何看待,工作那么多年了就没见过纯按标准来的 PATCH 或者 PUT 方法的接口

    顺便,楼主你的理解也并不准确,PUT 同样适用于新增
    learnshare
        9
    learnshare  
       2019-08-26 15:03:04 +08:00
    没有最佳实践,不专业才是正常的,多数上层应用不遵守协议也能凑合运行嘛

    @rockyou12 也不知道谁遇到过这个问题,并把他的垃圾经验推广开了
    ikaiguang
        10
    ikaiguang  
    OP
       2019-08-26 15:30:42 +08:00
    @mcfog

    嗯呢。上面的理解,摘自“ 阮一峰”的。
    ikaiguang
        11
    ikaiguang  
    OP
       2019-08-26 15:32:50 +08:00
    @Cyron
    @qq292382270

    我们的项目都是 post,不使用 get.

    为了贪图方便
    est
        12
    est  
       2019-08-26 15:49:10 +08:00   ❤️ 1
    挺好的。

    real world 如果只能用这 5 种方式操作资源简直是智障设定。比如我登出操作,如何对应这 5 种资源操作?
    mcfog
        13
    mcfog  
       2019-08-26 15:53:18 +08:00 via Android
    @est 可以当然是可以的,虚拟资源虚拟万物即可
    DELETE /session/current 或者 /session/:sid
    baiyi
        14
    baiyi  
       2019-08-26 16:10:24 +08:00   ❤️ 2
    不赞成所有的 API 都是用 POST

    但同样不赞成将 HTTP 方法对应 CRUD,例如说 POST:确实有“创建新资源”的语义,但是它还有“向数据处理过程提交数据块”的语义,这个“ data-handling process ”描述的太模糊了,所以 POST 方法完全可以替代 PUT、DELETE、PATCH,就像 HTML 的 form 标签,只支持 GET、POST,也完全符合语义的。在《 RESTful Web APIs 》这本书里叫它“ whatever ”......

    所以我个人更倾向于用业务逻辑的安全性、幂等性来定义 API 该是用哪种方法。

    举个例子:转账,使用 CRUD 就很难去对应,有的可能会用 PUT,因为修改了两个账户的余额信息,有的用 POST,但可能是强行将主体对象从账户转为转账记录这样的资源上,就会让人感觉很混乱。

    但如果使用幂等性来判断就很简单,PUT 幂等,POST 不幂等,那转账,肯定是不幂等的。按照这个思路换个例子:修改用户余额,可能这样的场景比较少,但主要是为了说明。这个就应该使用 PUT,应为它是幂等的。
    beyond99
        15
    beyond99  
       2019-08-26 16:18:21 +08:00
    @mcfog 这种为了 restful 而 restful 的方式有什么意义?只会让接口更难懂
    baiyi
        16
    baiyi  
       2019-08-26 16:23:35 +08:00
    @mcfog #13 不建议这样构建资源

    对于用户来说,POST “/user/logout ” 比 DELETE “/session ” 更容易理解,用户需要额外的去理解 session 这个资源的意义
    ArJun
        17
    ArJun  
       2019-08-26 16:28:44 +08:00
    所谓的规矩就是用来打破的,且意义上的 restful 都用 POSt 请求方式并没有什么影响
    wu67
        18
    wu67  
       2019-08-26 16:46:27 +08:00
    post 没什么毛病啊. 上面也说了 get 会被缓存, 这是其一; 统一 post 的话, 前端 /客户端封装请求方法也简洁很多, 不会出现 新来的菜鸡实习生搞不清楚为什么出错到处发问(笑) 的情况...
    hmzt
        19
    hmzt  
       2019-08-26 16:54:22 +08:00
    挺方便的,甚至一开始就不该设计那么复杂
    Vegetable
        20
    Vegetable  
       2019-08-26 17:12:11 +08:00   ❤️ 1
    挺方便的,信息更集中,通过 json 传递的参数带基本类型,减少犯错空间.比如 querystring 的 a=1&a=2 这种设计,很容易让新手犯错.

    你可能觉得不遵守规范是不对的,实际上这就是一种权衡,严格遵守 restful 很难,复杂业务下,只要有一份规则,大家共同遵守就可以,没有圣经.
    Cyron
        21
    Cyron  
       2019-08-26 17:16:03 +08:00
    @ikaiguang #11 json api 全用 post 也没问题,时间可以花在命名规范上
    westoy
        22
    westoy  
       2019-08-26 17:20:54 +08:00
    还有就是跨浏览器和避开一些防火墙对 delete、patch、put 的阻断, 你永远不知道真实世界里会出啥妖蛾子

    框架里最早提倡 REST 实践的是 rails 2 吧, 但是貌似直到现在 rails 都是通过 POST 传_method 字段来做的
    nnqijiu
        23
    nnqijiu  
       2019-08-26 17:29:49 +08:00
    都用 post
    otakustay
        24
    otakustay  
       2019-08-26 17:49:28 +08:00
    总比都用 GET 好,对吧
    est
        25
    est  
       2019-08-26 18:06:42 +08:00
    @mcfog 那带 CAPTCHA、2FA 的登入呢?

    验证邮箱的 API 呢?

    明明一个 资源名字 + 动词就能描述很清晰的东西,非得限定只用 5 个 verb 去套。。这是削足适履。

    而且正规的 RESTful 还要区分单数复数的。。这个就是个笑话。章鱼有 3 种复数形式。做 log 统计的时候就想把 RESTful 作者砍死。

    对了 RESTful 作者的发明其实就是 Adobe CodeFusion 没啥值得吹的。而且 RESTful 最好的应用也就 WebDAV 了。协议来说其实设计出发点听起来不错,用起来各种问题。性能也不高。
    mayne95
        26
    mayne95  
       2019-08-26 18:09:34 +08:00 via Android   ❤️ 2
    谢邀(并没有)
    既然楼主用知乎的提问体,那么我就用知乎的回答体。

    抛开业务场景谈 API 设计的都是耍流氓(加粗)

    规则是个约定俗称的东西,能减少沟通成本,但规则本身也有学习成本。如果 rest 是有 RFC 支持,白纸黑字明文规定的规则。那非常好,大家都按这个来,不会出什么幺蛾子。V 站也不会有人隔三差五的出来讨论 rest 规范。

    (不管对不对,先踩一番显得自己很高明的亚子)
    像 REST 这种含糊不清的约定本来就是一坨 shit,restful ful ful 风格你懂吗,你的 API 有自己的 freestyle 嘛?真是滑天下之大稽!正如 5 楼所说,rest 不是标准,不是标准,不是标准。API 能在符合 HTTP 协议的情况下运行起来即可。

    这个问题就像是,你觉得空格好还是 tab 好。又比如函数式之于面向对象。如果今后 graphql 普及,这个问题还有意义嘛?
    拿前朝的剑斩本朝的官?(大雾)

    在那个 API 风格混乱的年代,rest 的出现如同指路明灯。大家都按着这个来,减少了混乱,降低了沟通成本。这是值得肯定的。但是随着业务场景逐渐复杂,API 的设计已经没法完全符合 rest 的理念了。花心思去设计一个看起来美好的格式高度统一的 API,不如直接加个接口来的简单。

    全用 post 是有缺陷的。举个例子,如果前端要上 service worker,这时候 API 全用 post,请求是没法被拦截并缓存的,也就谈不上什么离线应用。这种场景下用 rest 是保险的。

    GitHub 的 API 堪称业界典范,程序员都喜欢。notion 获取数据全用的 post 请求,但这并不妨碍我喜欢它。重要的是产品。

    好的 API 是自描述的,能够自洽的,符合直觉的。用户在使用某个接口后,能够推导出其它接口的用法。API 面向的用户群体是程序员,对于程序员来说文档最重要。文档是最好的约定,rest 不 rest 无所谓啦。
    mcfog
        27
    mcfog  
       2019-08-26 21:25:29 +08:00 via Android
    @est 我说 restful 能做,又没说建议用 restful 做。

    如果你不懂怎么在一个 restful 风格的体系里设计符合 restful 风格的 2fa 也好 captcha 也罢我可以和你讨论一下我的想法,但我觉得你肯定没有兴趣

    哦对了,我也不喜欢 restful,但喜不喜欢一门技术和是否理解这门技术的优缺点,还有能否理性地讨论一门技术是三件不一样的事情,希望你不会因此错过一些更有价值或是有趣的技术
    artandlol
        28
    artandlol  
       2019-08-26 21:27:20 +08:00 via Android
    建议用 grpc 吧
    akira
        29
    akira  
       2019-08-26 22:13:13 +08:00
    文档齐全的 API 就是好 API
    dodo2012
        30
    dodo2012  
       2019-08-26 22:20:47 +08:00
    @westoy rails 到现在也是按 rustful 来的,所以写习惯 rails 后,写所有其它语言的接口全会自学按 restful,
    AngelCriss
        31
    AngelCriss  
       2019-08-26 23:08:43 +08:00 via Android
    不用 http 不就行了
    chocotan
        32
    chocotan  
       2019-08-26 23:13:02 +08:00
    从上面的回复来看,不同的人对 restful 理解会出现偏差
    那就别用了,全用 POST 吧
    chocotan
        33
    chocotan  
       2019-08-26 23:14:17 +08:00
    刚看到二楼...
    我的客户连 content-type 都不懂,指望对方懂这些 http method ?
    tedzhou1221
        34
    tedzhou1221  
       2019-08-27 08:13:00 +08:00 via Android
    我司现状,强制 Post + json 也不知道好不好,但我知道拍板的人不懂技术。
    liuxey
        35
    liuxey  
       2019-08-27 08:33:50 +08:00   ❤️ 1
    能完全参照 RESTful 的有几个,所以也不能 50 笑百,

    只要文档清晰, 沟通顺畅,工具好用,HTTP+XML 我也没意见
    est
        36
    est  
       2019-08-27 10:07:54 +08:00
    @mcfog 说得好。。。。
    switch100
        37
    switch100  
       2019-08-27 13:01:46 +08:00 via iPhone
    前端就是屁事多,给你 api 非得挑三拣四的,乖乖切页面不就可以了吗,还管到后端来了
    StarkWhite
        38
    StarkWhite  
       2019-08-27 17:23:30 +08:00
    GET, PUT, DELETE 等会对参数转义,调试麻烦,而且浏览器对字符长度限制也比较大,
    GraphQL 就是只用 HTTP POST 了,参数内用 query 和 mutation 标识,多简单~
    话说大家经常讨论的那个 APIJSON 也跟风全用 HTTP POST 了 /狗头
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5395 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 06:54 · PVG 14:54 · LAX 23:54 · JFK 02:54
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.