› httpbin - 协议调试工具
› httpstatuses - 协议状态码查询
› httpie - cURL-like tool for humans
Fiddler
leeraya
V2EX  ›  HTTP

Http 的 PUT 和 POST 如何分清?

  •  
  •   leeraya · Dec 30, 2020 · 5934 views
    This topic created in 2137 days ago, the information mentioned may be changed or developed.

    从功能上看,它们都能更新和新增。 怎么才能正确的区分使用场景呢。

    40 replies  •  2020-12-31 17:29:24 +08:00
    murmur
    murmur
    Dec 30, 2020
    1
    不用分清,从经验来看,我们只做 post 和 get,跟其他人解释另外两个语义太费口水
    murmur
    murmur
    Dec 30, 2020
    2
    甚至我们都不会一个接口做两个语义,语义化挺好,但是给别人解释和说明语义,以及跟不看文档的人联调踩坑太多

    还不如一个接口唯一用途,post 的接口数据少你拿 get 传我们也认,反之亦然
    TabGre
    TabGre
    Dec 30, 2020 via iPhone❤️2
    3
    鄙司后台:不用问,全是 post
    FinnBai
    FinnBai
    Dec 30, 2020❤️2
    4
    幂等性,POST 不幂等,PUT 幂等
    wysnylc
    wysnylc
    Dec 30, 2020
    5
    一个接口同时有多种操作,此时你用什么都是无法完全概括的
    写业务已经很费劲了还要去声明这个接口是 XX 属性只能 XX 操作,我看你是工作不饱和
    sadfQED2
    sadfQED2
    Dec 30, 2020 via Android
    6
    用哪个看我心情
    Pastsong
    Pastsong
    Dec 30, 2020
    7
    PUT 是幂等的,但在实际使用中大多场景都保证不了请求的幂等性,就连很多 GET 请求也不幂等,所以一般不用 PUT
    Jooooooooo
    Jooooooooo
    Dec 30, 2020
    8
    通通用 post 即可
    newtype0092
    newtype0092
    Dec 30, 2020
    9
    每次看到人讨论 RESTful 的 method 含义就像在做阅读理解。。。
    sinxccc
    sinxccc
    Dec 30, 2020
    10
    自己跟服务器商量好就行了…
    auin
    auin
    Dec 30, 2020
    11
    做着做着,最终都是 POST 一把梭
    f6x
    f6x
    Dec 30, 2020❤️1
    12
    IETF: 30 年前我们是这么设计的,blabla
    RESTful: 设计很好,我们现在是这么标准化的, blabla
    程序员: 什么? 只会 POST
    est
    est
    Dec 30, 2020
    13
    RESTful 没文化

    OPTIONS + POST 打天下。
    otakustay
    otakustay
    Dec 30, 2020
    14
    PUT 的 URI 对应**唯一**的资源,POST 的 URI 对应资源的**集合**
    ai277014717
    ai277014717
    Dec 30, 2020
    15
    put by id
    Leonard
    Leonard
    Dec 30, 2020
    16
    我是发现这些都没人用,全是 GET 和 POST
    Finest
    Finest
    Dec 30, 2020
    17
    关键你服务端 Restful 玩得再溜,每次跟客户端对接还得再解析一遍
    jtsai
    jtsai
    Dec 30, 2020 via iPhone
    18
    语义不同
    laoyur
    laoyur
    Dec 30, 2020
    19
    @f6x blah
    icew4y
    icew4y
    Dec 30, 2020 via iPhone❤️1
    20
    restful 把简单的事情复杂化了
    imgbed
    imgbed
    Dec 30, 2020
    21
    API 的话,我全部用 POST,好像没什么问题
    imdong
    imdong
    Dec 30, 2020
    22
    目前也就 post get delete,容易识别的。

    写 post
    读 get
    删 delete

    其他得不解释,而且使用 delete 之前还特意和客户端沟通说没问题。
    charlie21
    charlie21
    Dec 30, 2020 via iPhone
    23
    用 PUT 也可以没幂等性
    litchinn
    litchinn
    Dec 30, 2020
    24
    我理解的 Restful 是面向资源的,在 restful 中不应该使用`/user/add`等,所以 CRUD 对应的 URI 只有一个,例如`/user`,你新增都已经把 POST 用了,修改自然只能 PUT 了
    tinyRat
    tinyRat
    Dec 30, 2020
    25
    看似前后端分离,接口用 post 梭哈。
    leafre
    leafre
    Dec 30, 2020
    26
    都用 post
    GG668v26Fd55CP5W
    GG668v26Fd55CP5W
    Dec 30, 2020 via iPhone
    27
    restful 在实际应用各种变形,算了,post 一把梭
    anmie
    anmie
    Dec 30, 2020❤️2
    28
    get:从服务器获取数据

    post:向服务器增加数据

    put:修改服务器已有数据

    del:删除服务器已有数据
    draguo
    draguo
    Dec 30, 2020
    29
    restful 看着很美好,实际使用不如都 post 方便
    strongcoder
    strongcoder
    Dec 30, 2020 via iPhone
    30
    全部都用 post
    tonyaiken
    tonyaiken
    Dec 31, 2020 via iPhone
    31
    我们公司是严格按照语义的,内部也有指南。同事不按指南定义会被打回的。
    106npo
    106npo
    Dec 31, 2020 via Android
    32
    put 和 patch 才有语意的近似,put 全量修改,patch 部分修改。
    至于 post 和 put,你把 post 当修改,那你用什么做新增?
    ghostsf
    ghostsf
    Dec 31, 2020 via iPhone
    33
    严格按 restful 执行还是香的
    FinnBai
    FinnBai
    Dec 31, 2020
    34
    @Pastsong #7 GET 是安全的,所以一定是幂等的,绝大多数 GET 都应该是安全的操作

    在我的理解中,幂等不代表每次请求的响应内容相等,而是指重复一个请求对服务造成的后果是相等的。简言之就是这个请求是可以重试的。
    bsg1992
    bsg1992
    Dec 31, 2020
    35
    @baiyi 很难达到 N 次请求后 “对服务造成的后果是相等” 每次请求服务端 都会触发变更
    h82258652
    h82258652
    Dec 31, 2020
    36
    GET 只读,幂等
    POST 新增,不幂等
    DELETE 删除,幂等
    PUT 修改,幂等

    其它没法分的通通都扔到 POST 里,例如 Login 、SendEmail 这种的。
    PATCH 基本不用,因为 PATCH json 处理起来稍微麻烦点。
    FinnBai
    FinnBai
    Dec 31, 2020
    37
    @bsg1992 #35 这个“对服务造成的后果是相等的“是基于业务逻辑的。

    用 Github starred 请求来举例,这个操作就是典型的 PUT 操作,因为你对一个仓库请求 N 次,业务逻辑也都是 starred 。想要取消,需要请求 DELETE 方法的 starred 接口。

    假如 Github 不按照上面的业务逻辑设计,而是改为“你对一个 starred 仓库再次请求,会取消 star”。基于这个业务逻辑,starred 接口就要设计为 POST 。

    但可能我重试了 N 次之后,N+1 次被服务器拦截了,它认为我是恶意攻击,这与业务逻辑无关,只是从安全性上考虑,也与 HTTP method 语义无关。
    julyclyde
    julyclyde
    Dec 31, 2020
    38
    POST 的那个网址一般是个程序
    PUT 的一般是要上传的内容将来的名字
    bsg1992
    bsg1992
    Dec 31, 2020
    39
    @baiyi
    用手机验证码这个功能来说,按照 restful 定义他应该是一个获取资源的描述。
    实际上来它涉及到了多个状态的变更,每一次的请求都会影响到改接口的内部处理逻辑和返回状态,他的接口风控也是基于业务要求来做的。
    FinnBai
    FinnBai
    Dec 31, 2020
    40
    @bsg1992 #39 应该从业务逻辑上理解接口,从而使用更合适的 POST 方法,而不是单纯的从“获取验证码”这个描述上理解。

    在我看来设计接口时更应该考虑的是接口的安全性与幂等性,很明显,这个操作即不安全也不幂等,所以 POST 最合适。
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Privacy   ·   Solana   ·   2179 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 74ms · UTC 12:49 · PVG 20:49 · LAX 04:49 · JFK 07:49
    ♥ Do have faith in what you're doing.