为什么我们在 Restful API 中使用不同的动词？答案

【问题标题】：Why do we use different verbs in Restful APIs?为什么我们在 Restful API 中使用不同的动词？
【发布时间】：2018-10-09 16:35:20
【问题描述】：

除了“最佳实践”和“创建标准”的明显答案之外，是否存在使用 GET、POST、PUT、DELETE 等而不是使用 POST 做所有事情的技术论据？

【问题讨论】：

一个原因是 url 应该标识您在谈论关于的内容，以便“获取该员工”和“更新该员工”不需要两个不同的端点.
他们可以用不同的动词来做到这一点，如果这是唯一的原因，那么动词就不会那么混乱了。我的意思是把 PUT 和 PATCH 作为一个令人困惑的例子。

标签： rest

【解决方案1】：

除了创建Uniform Interface，不同的动词有不同的属性：

safe (GET, HEAD, OPTIONS, TRACE)

区分安全和不安全方法的目的是允许自动检索过程（蜘蛛）和缓存性能优化（预取）工作而不必担心造成伤害。

idempotent (PUT, DELETE, GET, HEAD, OPTIONS, TRACE)

幂等方法的区别在于，如果在客户端能够读取服务器的响应之前发生通信故障，请求可以自动重复。

cacheable: (GET, HEAD, POST)

请求方法可以定义为“可缓存的”，表示允许存储对它们的响应以供将来重用；

构成“互联网”的所有中间服务器都依赖统一接口和这些属性才能正常工作。这包括内容交付网络、代理和缓存。正确使用动词有助于互联网更好地工作。

【讨论】：

另外，说得好。

【解决方案2】：

对于使用 GET、POST、PUT、DELETE 等而不是使用 POST 做所有事情，是否存在技术论据？

是的。

在 HTTP 的情况下，选择 GET 而不是 POST 的重要原因之一是缓存。 RFC 7234 定义了一堆缓存语义，可以写入消息（特别是头部）。

计算机科学中一个有趣的问题是缓存失效；在 HTTP 中，invalidation 有一个与方法相关的特定语义：

当接收到非错误状态代码时，缓存必须使有效的请求 URI（[RFC7230] 的第 5.5 节）以及 Location 和 Content-Location 响应头字段（如果存在）中的 URI 无效响应不安全的请求方法。

换句话说，POST 和 GET（也是 HEAD）之间的部分区别在于通用客户端知道使缓存的资源表示无效。因此，我可以使用第三方无头浏览器与您的 API 通信，并且缓存“正常工作”。

POST 和其他不安全方法之间的界限不太清楚，但存在。基本大纲是POST 可以表示任何含义——但PUT 和DELETE 都专门描述了idempotent operations。所以再一次，如果消息在不可靠的网络上丢失，我不需要定制一个做正确事情的客户端——我可以使用与域无关的 HTTP 客户端来 PUT 和 DELETE，并且重新广播丢失的消息可以再次“只是工作”。

方法之间区别的力量在于我们可以创建和重用知道 HTTP 语义的通用中间组件（无头浏览器、缓存、反向代理），并且（因为我们已经使用这些语义描述了我们的域协议）它们都“正常工作”——通用组件即使不知道到底发生了什么，也能做有用的工作。

【讨论】：

好的，知道了。现在很有意义。

【解决方案3】：

这些动词是 HTTP 规范的一部分，这是我们在通过 HTTP 进行 REST 时使用它们的主要原因，并且在早期我们开始通过 HTTP 进行 REST，因此它们成为最佳实践的一部分。

【讨论】：

RFC 2616 自 2014 年以来已过时。请参考 RFC 7230-7235 了解更新的 HTTP/1.1 规范。
这是我发现的第一个热门歌曲，无论如何它都正确解释了动词。我还是删除了它，因为它不会影响答案。