rest - 如何在 REST API 中正确使用 HTTP 请求方法？

我偶然发现了很多引用“PUT 不属于 REST API”和“在现代 API 中应该只使用 GET 和 POST”的引用。

我不会在这些引文中放太多股票——它们暗示着对 REST、HTTP 以及一切应该如何组合在一起的理解不足。

我建议从Jim Webber开始，他确实有很好的理解。

HTTP 是一种应用协议，其应用领域是网络上的文档传输。

PUT、PATCH、DELETE 都是描述文档更改的完美方法。我GET是您的文档，我使用我最喜欢的 HTTP 感知编辑器/库来更改文档，我向您发送一个请求，描述我对文档的更改，您可以弄清楚最终要做什么。

这让我想知道，为什么不在 REST API 中使用 PUT 或 PATCH 或 DELETE 等？这不是他们的目的吗？因为它们有助于语义和结构等而被使用？

您可能不这样做的一个原因：您选择的媒体类型是 HTML——HTML 对链接 (GET) 和表单 (GET/POST) 具有原生支持，但在涉及其他方法的方式方面没有很多直接支持。流动。对于支持它的客户，您可以使用按需代码。

它可能与例如接收请求的方法有关吗？主要是将数据引导到其他方法的方法，例如然后处理它们的数据库方法？我在想要更新文档时使用了 PUT，但它从未覆盖文档，即使我只向它发送了部分数据。

关于 HTTP 方法的重要理解是它们描述的是语义，而不是实现。这是菲尔丁在 2002 年写的：

HTTP 不尝试要求 GET 的结果是安全的。它的作用是要求操作的语义是安全的，因此如果发生任何导致财产损失的事情，那是实现的错误，而不是接口或该接口的用户

在PUT的特定情况下，语义的含义有一个额外的提示

给定表示的成功 PUT 将表明对同一目标资源的后续 GET 将导致在 200（OK）响应中发送等效表示。但是，不能保证这种状态变化是可观察到的......

我认为 Triynko 提出了一个很好的观点：

大多数现代应用程序中标识的 URI 不是要替换、更新等的资源。它们不是文档。他们正在调用程序。

如果您正在创建一个以过程为中心的 API，而不是一个以资源为中心的 API，那么 PUT/PATCH/DELETE 很可能实际上并没有提供证明额外复杂性合理性的好处。

一个提示您专注于过程：您对缓存失效付出了多少关注？接受“统一接口”约束的部分原因是您想要通用组件可以提供的功能，而在 HTTP 中，缓存很重要。