我从未使用过 PUT 或 DELETE HTTP 请求方法。我倾向于在系统状态（我的应用程序或网站）可能不受影响（如产品列表）时使用 GET，并在受影响时（如下订单）使用 POST。这两个不是总是足够的，还是我错过了什么？
【问题讨论】：
标签： http httprequest
DELETE 用于删除请求资源：
DELETE 方法请求源服务器删除由 Request-URI 标识的资源。此方法可能会被源服务器上的人工干预（或其他方式）覆盖。客户端不能保证操作已经执行，即使源服务器返回的状态码表明操作已经成功完成……
PUT 用于在服务器上放置或更新资源：
PUT 方法请求将封闭的实体存储在提供的 Request-URI 下。如果 Request-URI 引用了一个已经存在的资源，封闭的实体应该被认为是在源服务器上的一个修改版本。如果 Request-URI 不指向现有资源，并且该 URI 能够被请求用户代理定义为新资源，则源服务器可以使用该 URI 创建资源……
如需完整规格，请访问：
Since current browsers unfortunately do not support any other verbs than POST and GET in HTML forms，您通常无法充分利用 HTTP 与他们（尽管您仍然可以通过 JavaScript 劫持他们的提交）。 HTML 表单中不支持这些方法导致 URI 包含动词，例如
POST http://example.com/order/1/delete
甚至更糟
POST http://example.com/deleteOrder/id/1
通过 HTTP 有效地隧道化 CRUD 语义。但是动词从来都不是 URI 的一部分。相反，HTTP 已经通过 HTTP 方法提供了对资源（例如订单）进行 CRUD 的机制和语义。 HTTP 是一种协议，而不仅仅是一些数据隧道服务。
所以要删除网络服务器上的资源，你需要调用
DELETE http://example.com/order/1
并且要更新它你会调用
PUT http://example.com/order/1
并在 PUT 正文中提供更新的资源表示供网络服务器随后应用。
因此，如果您正在为REST API 构建某种客户端，您可能会使其发送 PUT 和 DELETE 请求。这可能是在浏览器中构建的客户端，例如通过 JavaScript 发送请求，或者它可能是在服务器上运行的某个工具等。
更多详情请访问：
【讨论】：
使用 HTTP 请求动词，如 GET、POST、DELETE、PUT 等...使您能够构建 RESTful Web 应用程序。在这里阅读：http://en.wikipedia.org/wiki/Representational_state_transfer
查看此示例的好处的最简单方法是查看此示例。
每个 MVC 框架都有一个 Router/Dispatcher 将 URL-s 映射到 actionController。
所以像这样的 URL：/blog/article/1 会调用 blogController::articleAction($id);
现在这个路由器只知道 URL 或/blog/article/1/
但是，如果路由器知道整个 HTTP 请求对象而不仅仅是 URL，他就可以访问 HTTP 请求动词（GET、POST、PUT、DELETE...），以及有关当前 HTTP 请求的许多其他有用的东西。
这将使您能够配置应用程序，以便它可以接受相同的 URL 并根据 HTTP 请求动词将其映射到不同的 actionController。
例如：
如果您想检索第 1 条，您可以这样做：
GET /blog/article/1 HTTP/1.1
但如果你想删除第 1 条，你会这样做：
DELETE /blog/article/1 HTTP/1.1
请注意，两个 HTTP 请求具有相同的 URI，/blog/article/1，唯一的区别是 HTTP 请求动词。并且基于那个动词，你的路由器可以调用不同的 actionController。这使您能够构建整洁的 URL-s。
阅读这两篇文章，它们可能会对你有所帮助：
这些文章是关于 Symfony 2 框架的，但它们可以帮助您弄清楚 HTTP 请求和响应是如何工作的。
希望这会有所帮助！
【讨论】：
Create 为 1，Delete 为 1。如果您这样做，您的下一个搜索将是“如何在单个控制器中拥有多个 Post 操作”：P。并不是说这很糟糕，但是您失去了通过动词操作实现唯一资源的能力，而不必在 URI 中显式提供操作名称。
虽然我冒着不受欢迎的风险，但我说它们现在没用了。
我认为它们在过去是很好用的，例如 DELETE 告诉服务器删除在提供的 URL 中找到的资源，而 PUT（及其同级 PATCH）告诉服务器以幂等方式进行更新。
随着事情的发展，URL 变得虚拟（例如，参见 url 重写）使得资源失去了真正的文件夹/子文件夹/文件的初始含义，因此 HTTP 协议方法（GET、 POST、PUT/PATCH、DELETE）丢失了轨道。
举个例子：
左边没有写 HTTP 方法，本质上没关系（POST 和 GET 就足够了），右边使用了适当的 HTTP 方法。
右侧看起来优雅、干净、专业。想象一下，现在您必须维护一个一直在使用优雅 API 的代码，并且您必须搜索删除调用的完成位置。您将搜索 "api/entity" 并在结果中查看哪个正在执行 DELETE。或者更糟糕的是，你有一个初级程序员错误地将 PUT 切换为 DELETE 并且 URL 发生了同样的事情。
在我看来，将动作动词放在 URL 中比为该动作使用适当的 HTTP 方法具有优势，即使它不是那么优雅。如果您想查看删除调用的位置，只需搜索 "api/entity/delete" 即可立即找到。
在没有整个 HTTP 方法数组的情况下构建 API 可以更容易地在之后使用和维护
【讨论】：
myEntity.Delete()，或在方法DeleteEntity() 中。然后它必须对任何人都清晰可见。
安全方法：获取资源/不修改资源
幂等：如果多次请求，资源状态不会改变
不安全方法： 在资源中创建或更新资源/修改
非幂等： 如果多次请求，资源状态会发生变化
根据您的要求：
1) 为了安全和幂等操作（获取资源）使用 --------- GET METHOD
2) 对于不安全和非幂等操作（插入资源）使用--------- POST METHOD
3) 对于不安全和幂等操作（更新资源）使用--------- PUT METHOD
3) 对于不安全和幂等操作（删除资源）使用--------- DELETE METHOD
【讨论】：
查看@Gordon 接受的答案，关键点很简单：
PUT 和 DELETE 是具有含义的特定动词，指示服务器执行特定操作以及应如何处理指令。
如果我们说，“好吧，但我更容易通过向我的 URI 发出一个具有路径 /api/entity/delete/{id} 的 GET 来执行删除操作（正如 @Bogdan 的回答中所建议的那样）。好吧，让我们看看在 GET 的定义中：
GET 方法意味着检索任何信息（以 entity) 由 Request-URI 标识
来源 - W3C 标准 - https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
如果您将GET 用于DELETE，那么根据其标准定义，您显然是在滥用该方法。
好吧，让我们进一步说“好的，但这并不重要，因为对于开发人员来说，在某处使用 GET 方法读取 URI 并读取 /api/entity/delete/{id} 而不是使用删除资源的 DELETE 方法更实用与检索的 GET 方法相同的签名，以便开发人员了解这是为了删除。让我们考虑一个结构良好的 DELETE 方法签名（示例适用于 .NET Core 5）：
// DELETE: api/TodoItems/5
[HttpDelete("{id}")]
public async Task<IActionResult> DeleteTodoItem(long id)
{
这不会响应获取请求，（例如，在调用 API 时意外删除而不是检索会受到更多保护 - 开发人员必须显式执行删除请求以API）。而且我们有一个非常清晰、结构良好且命名的 API 操作，开发人员甚至自动化工具都可以清楚地发现它（例如，开发人员现在可以专门搜索代码中任何出现的 DELETE，或者搜索清楚的方法名称）表示删除）。更重要的是，这种模式符合普遍接受的“RESTFUL”API 标准，应该使 API 更广泛地被开发人员（以及可能的任何自动化工具）识别和解释。
好的，这很好，但是将其设为 DELETE 的真正区别是什么？为什么还要使用 DELETE 而不是 GET？我的操作是从数据库中删除一些东西，我的网络服务器为什么要关心？ OK，我们来想想DELETE的定义：
9.7 DELETE - DELETE 方法请求源服务器删除由 Request-URI 标识的资源。这种方法可能是 被原点上的人为干预（或其他方式）覆盖 服务器。
所以现在，如果我们指定删除，我们有可能在服务器上出现特定行为，这可能允许通过手动或自动干预来撤销删除操作。在特定用例中，这可能很重要。
我个人通常在实现对数据库进行操作的 API 时执行此操作，尽管 PUT 也有特定含义，即它具体表示资源的更新，而 POST 表示创建，所以使用 POST 来创建和更新是反标准的。我自己的观点是，当我通常认为 upsert 功能的实用性比严格使用正确的动词来添加与插入更重要时，REST API 是一种情况，但我可能会在这里遗漏一些东西。
在 REST api 之外使用 PUT 对于实际目的可能更重要，例如，如果我们正在执行更新操作，其中服务器可以通过了解资源已更新来潜在地清除任何缓存（这更重要例如，如果我们的资源是一个完整的文档）。在 RESTful API 中使用 PUT 进行更新操作时，可能会有一些我没有考虑过的实际优势。
POST 的标准定义声明 POST 成功响应应该是 201（已创建），而不仅仅是通用的“200 OK”，以便我们能够正确解释资源创建显式成功。该响应不适用于更新操作，但标准中没有为响应代码指定“必须”。开发人员使用 POST 进行 upsert 并在成功时返回 200（OK）当然很常见，无论是创建还是更新。
PUT 的标准更为严格，并指定在尝试更新时任何意外创建的资源都必须通过 201 响应代码来指示。如果指定 URI 中不存在现有资源，则可能发生这种情况。该标准解释说，如果我们使用 PUT，我们会得到更清晰的反馈，说明我们尝试更新操作的结果是否符合我们的预期。
来自 W3C 标准：
[如果 put] 不指向现有资源，并且该 URI 是 能够被请求用户定义为新资源 代理，源服务器可以使用该 URI 创建资源。如果一个 创建新资源，源服务器必须通知用户代理 通过 201（已创建）响应。如果修改了现有资源， 应该发送 200 (OK) 或 204 (No Content) 响应代码 表示请求成功完成。
【讨论】：
当您需要更改资源时，使用PUT 方法。资源，它已经是资源集合的一部分。这里需要注意的一点是PUT 方法修改整个资源，而PATCH 方法用于修改资源或数据的必要部分。
顾名思义，DELETE请求方法用于删除指定资源。它请求源服务器删除由 Request-URL 标识的资源。
我希望这个简单的定义有所帮助。
【讨论】：