如果我理解正确，则GET是安全的，因此可以将其缓存。 GET，PUT和DELETE是幂等的，因此可以重试（还有其他好处吗？）。但是POST和PATCH既不安全又不是幂等的呢？区分它们有什么意义？另外，我的理解是正确的，因为GET，PUT，PATCH，DELETE都是状态更改方法，因此有助于使先前GET请求对相同资源的缓存无效（即，如果跟踪配方，则/ recipes的GET将被缓存直到向/配方发出POST / PUT / PATCH / DELETE请求）？那么像GraphQL这样的仅使用GET和POST的API设计架构又如何呢？如果没有自定义实现，它是否没有重试和缓存无效的优势？
答案 0 :(得分：1)
如果我理解正确，则GET是安全的，因此可以将其缓存。
不完全是。 GET是safe，也就是说无害。因此，机器可以抢先发出请求以获取资源表示。您可能这样做的原因之一是预加载了缓存；但可能是您只是尝试索引API。可能是网络不稳定，如果响应不及时，您想自动重新发出请求。
但是不安全且不等幂的POST和PATCH又如何呢？区分它们有什么意义？
PATCH比POST具有更具体的语义，这意味着通用客户端对正在发生的事情有更多的了解。
更准确地说，PATCH就像PUT；两者都是请求服务器修改其资源表示形式以匹配客户端的本地表示形式。例如，我们可以使用HTTP感知的JSON编辑器来修改资源的本地表示形式，然后编辑器可以选择是将整个表示形式发送到服务器（PUT），还是仅发送编辑内容（PATCH）。 / p>
另一方面，POST可以是任何 －它可能是通过HTTP隧道传输的其他协议（SOAP或GraphQL），它可能是带有文档有效负载的只读搜索，可能是完全与当前资源表示无关的HTTP表单提交。
PATCH规范还为您提供语义，以发现给定资源支持的补丁文件类型。
此外，我的理解是正确的，因为GET，PUT，PATCH，DELETE都是状态更改方法，因此有助于使对相同资源的先前GET请求的缓存无效
不，GET是安全的，它不会使任何内容无效（这里要考虑的边缘情况是具有多个表示形式的资源-GET允许您将新的表示形式下载到缓存中而不会使旧的表示形式无效）。
PUT / PATCH / DELETE都是不安全的，因此将使用target-uri使缓存条目无效。参见RFC 7234。
那么像GraphQL这样的仅使用GET和POST的API设计架构又如何呢？
GraphQL与之前的SOAP一样，为了其他优势（例如，与传输协议无关的消息隧道）而折衷了HTTP内置的一些功能。
为GET请求“预加载缓存”到底是什么意思？
思考网络浏览器。你去谷歌，并获得多页的搜索结果。当您仍在查看页面1上的链接时，浏览器可以开始缓存页面2，页面3，页面4。因此，当您决定单击page-2链接时，可能会大大减少延迟。
此外，浏览器可以执行此操作，而无需了解有关链接平均含义的任何信息。