3 回答
TA贡献1786条经验 获得超13个赞
PUT
用于创建/替换您指定的 URI 处的资源。
因此,如果一个资源存在,它有一个客户端知道的 URI,并且通过请求PUT
替换那里的内容,这PUT
是最有意义的。
PUT
相对于 POST的一大好处是PUT
幂等性。
PUT
因此,如果您向端点发送请求/myTable
,则隐含的含义是您正在替换 ,并且同一端点上的myTable
后续请求将为您提供与刚刚发送的内容在语义上相似的响应。GET
如果我的上述任何假设是错误的,您很可能会想要POST
,这更像是一种通用的包罗万象的方法,可以在较少的限制下进行更改。POST
缺点是,我认为在不检查/理解主体的情况下,给定请求的操作不太明显,并且您也会失去幂等性的好处。
TA贡献1788条经验 获得超4个赞
目前我使用 POST 但我不知道这是否合适。
规则#1:如果您不确定,可以使用 POST。
POST 在 HTTP 中具有许多有用的用途,包括“此操作不值得标准化”的一般用途。
看来使用 PUT 也可以正常工作。
从某种意义上说,任何方法在源服务器上“都能正常工作”。HTTP 定义了请求语义——消息的含义。它不限制实施。
然而,通用客户端会假设您的服务器理解 GET/HEAD/POST/PUT 等,就像其他 Web 服务器理解它们一样。这是 REST 架构风格的强大功能的重要组成部分 - 任何符合标准的客户端都可以与任何符合标准的服务器进行通信,并且它可以正常工作。此外,如果我们在它们之间插入任何符合标准的缓存/代理,它会继续以完全相同的方式工作。
但是,如果您使用204 No Content响应PUT请求,那么通用组件将理解这与任何其他服务器返回的含义相同。也就是说,如果你偏离标准而导致财产损失,你的服务员要承担责任。
TA贡献1772条经验 获得超8个赞
您可以在这里查看答案以供参考。它们得到了很好的解释。 REST 中的 PUT 与 POST
但由于两者可以达到相同的目的,并且仅取决于您的偏好或要求,因此我通常使用 post 来创建资源并更新资源作为一种实践。
添加回答
举报