Http 的 PUT 和 POST 如何分清？

• 資深大佬 : murmur

  不用分清，从经验来看，我们只做 post 和 get，跟其他人解释另外两个语义太费口水

• 資深大佬 : murmur

  甚至我们都不会一个接口做两个语义，语义化挺好，但是给别人解释和说明语义，以及跟不看文档的人联调踩坑太多

  还不如一个接口唯一用途，post 的接口数据少你拿 get 传我们也认，反之亦然

• 資深大佬 : TabGre

  鄙司后台：不用问，全是 post

• 資深大佬 : baiyi

  幂等性，POST 不幂等，PUT 幂等

• 資深大佬 : wysnylc

  一个接口同时有多种操作,此时你用什么都是无法完全概括的
  写业务已经很费劲了还要去声明这个接口是 XX 属性只能 XX 操作,我看你是工作不饱和

• 資深大佬 : sadfQED2

  用哪个看我心情

• 資深大佬 : Pastsong

  PUT 是幂等的，但在实际使用中大多场景都保证不了请求的幂等性，就连很多 GET 请求也不幂等，所以一般不用 PUT

• 資深大佬 : Jooooooooo

  通通用 post 即可

• 資深大佬 : newtype0092

  每次看到人讨论 RESTful 的 method 含义就像在做阅读理解。。。

• 資深大佬 : sinxccc

  自己跟服务器商量好就行了…

• 資深大佬 : liuxey

  做着做着，最终都是 POST 一把梭

• 資深大佬 : f6x

  IETF: 30 年前我们是这么设计的,blabla
  RESTful: 设计很好,我们现在是这么标准化的, blabla
  程序员: 什么? 只会 POST

• 資深大佬 : est

  RESTful 没文化

  OPTIONS + POST 打天下。

• 資深大佬 : otakustay

  PUT 的 URI 对应**唯一**的资源，POST 的 URI 对应资源的**集合**

• 資深大佬 : ai277014717

  put by id

• 資深大佬 : Leonard

  我是发现这些都没人用，全是 GET 和 POST

• 資深大佬 : hand515

  关键你服务端 Restful 玩得再溜，每次跟客户端对接还得再解析一遍

• 資深大佬 : jtsai

  语义不同

• 資深大佬 : laoyur

  @f6x blah

• 資深大佬 : icew4y

  restful 把简单的事情复杂化了

• 資深大佬 : imgbed

  API 的话，我全部用 POST，好像没什么问题

• 資深大佬 : imdong

  目前也就 post get delete，容易识别的。

  写 post
  读 get
  删 delete

  其他得不解释，而且使用 delete 之前还特意和客户端沟通说没问题。

• 資深大佬 : charlie21

  用 PUT 也可以没幂等性

• 資深大佬 : litchinn

  我理解的 Restful 是面向资源的，在 restful 中不应该使用`/user/add`等，所以 CRUD 对应的 URI 只有一个，例如`/user`，你新增都已经把 POST 用了，修改自然只能 PUT 了

• 資深大佬 : tinyRat

  看似前后端分离，接口用 post 梭哈。

• 資深大佬 : leafre

  都用 post

• 資深大佬 : falcon05

  restful 在实际应用各种变形，算了，post 一把梭

• 資深大佬 : anmie

  get：从服务器获取数据

  post：向服务器增加数据

  put：修改服务器已有数据

  del：删除服务器已有数据

• 資深大佬 : draguo

  restful 看着很美好，实际使用不如都 post 方便

• 資深大佬 : strongcoder

  全部都用 post

• 資深大佬 : tonyaiken

  我们公司是严格按照语义的，内部也有指南。同事不按指南定义会被打回的。

• 資深大佬 : xmumiffy

  put 和 patch 才有语意的近似，put 全量修改，patch 部分修改。
  至于 post 和 put，你把 post 当修改，那你用什么做新增？

• 資深大佬 : ghostsf

  严格按 restful 执行还是香的

• 資深大佬 : baiyi

  @Pastsong #7 GET 是安全的，所以一定是幂等的，绝大多数 GET 都应该是安全的操作

  在我的理解中，幂等不代表每次请求的响应内容相等，而是指重复一个请求对服务造成的后果是相等的。简言之就是这个请求是可以重试的。

• 資深大佬 : bsg1992

  @baiyi 很难达到 N 次请求后 “对服务造成的后果是相等” 每次请求服务端 都会触发变更

• 資深大佬 : h82258652

  GET 只读，幂等
  POST 新增，不幂等
  DELETE 删除，幂等
  PUT 修改，幂等

  其它没法分的通通都扔到 POST 里，例如 Login 、SendEmail 这种的。
  PATCH 基本不用，因为 PATCH json 处理起来稍微麻烦点。

• 資深大佬 : baiyi

  @bsg1992 #35 这个“对服务造成的后果是相等的“是基于业务逻辑的。

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

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

  但可能我重试了 N 次之后，N+1 次被服务器拦截了，它认为我是恶意攻击，这与业务逻辑无关，只是从安全性上考虑，也与 HTTP method 语义无关。

• 資深大佬 : julyclyde

  POST 的那个网址一般是个程序
  PUT 的一般是要上传的内容将来的名字

• 資深大佬 : bsg1992

  @baiyi
  用手机验证码这个功能来说，按照 restful 定义他应该是一个获取资源的描述。
  实际上来它涉及到了多个状态的变更，每一次的请求都会影响到改接口的内部处理逻辑和返回状态，他的接口风控也是基于业务要求来做的。

• 資深大佬 : baiyi

  @bsg1992 #39 应该从业务逻辑上理解接口，从而使用更合适的 POST 方法，而不是单纯的从“获取验证码”这个描述上理解。

  在我看来设计接口时更应该考虑的是接口的安全性与幂等性，很明显，这个操作即不安全也不幂等，所以 POST 最合适。