REST DELETE idempotency

Question

如果DELETE请求将删除整数索引处的资源，那么在该索引处重新创建资源的可能性是否会破坏严格的幂等性？

e.g。向/ api / resource / 123发出DELETE请求，在123处删除该资源。然后发出一个post请求，该请求创建一个新资源，该资源可以通过GET请求检索到同一个url。

在我看来，为了使原来的DELETE具有正确的幂等性，API不应该创建一个具有先前使用的id的新的，不同的资源，但是我找不到明确的引用。

Answer 1

  

如果DELETE请求将删除整数索引处的资源，那么在该索引处重新创建资源的可能性是否会破坏严格的幂等性？

没有

RFC 7231

  

请求方法被视为＆＃34;幂等＆＃34;如果使用该方法对服务器的多个相同请求的预期效果与单个此类请求的效果相同。

     

区分幂等方法，因为如果在客户端能够读取服务器响应之前发生通信故障，则可以自动重复请求。例如，如果客户端发送PUT请求并且在收到任何响应之前关闭了底层连接，则客户端可以建立新连接并重试幂等请求。它知道重复请求将具有相同的预期效果，即使原始请求成功，尽管响应可能不同。

注意：通用客户端可以重试请求;客户并不需要了解您的具体实施情况。

  

在我看来，为了使原始的DELETE具有正确的幂等性，API不应该创建一个具有以前使用的id的新的，不同的资源，但我找不到明确的引用。

根本不是这样的。想想静态网站。你可以，网站所有者，删除foobar.html吗？当然可以。你以后可以重新创建吗？当然。如果这是真的，那么对于远程编辑也应如此。

如果对于网站的远程编辑是正确的，那么任何其他REST API也应如此。统一界面的点是消费者不需要知道他们是在与文件系统，文档存储，数据库还是某些复杂的服务进行通信。 API的工作是充当集成层，以便底层实现就像Web一样。

Answer 2

实际上，这与方法的幂等行为无关。 这是命名资源的问题。因为如果资源从未存在过，则删除操作将与删除资源后的操作完全相同。 是的，第二个请求将删除具有相同名称的新资源。 但是，如果您遇到此问题，只需创建一个唯一的资源名称。（例如UUID） 您也可以尝试使用数据库索引。即使输入密钥＆＃34; 123＆＃34;被删除 - 数据库不再创建它。