Http 的 PUT 和 POST 如何分清？

[leeraya]

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

[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 最合适。