REST DELETE 幂等性
REST DELETE idempotency
给定删除整数索引处资源的 DELETE 请求，在该索引处重新创建资源的可能性是否会破坏严格的幂等性？
例如对 /api/resource/123 发出的 DELETE 请求会删除 123 处的资源。然后会发出 post 请求，该请求会创建一个新资源，可以通过对同一 url 的 GET 请求检索该资源。
在我看来，要使原始 DELETE 正确地幂等，API 永远不应该使用以前使用过的 ID 创建一个新的、不同的资源，但我找不到明确的参考。
事实上，这与方法的幂等行为无关。
这就是命名资源的问题。因为如果资源从未存在过，则删除的行为与资源被删除后的行为完全相同。
是的，第二个请求将删除具有相同名称的新资源。
但是如果您遇到这个问题，只需创建一个唯一的资源名称。（例如 UUID）
您也可以尝试使用数据库索引。即使删除了键为“123”的条目 - 数据库也不会再次创建它。
Given a DELETE request that will delete resource at an integer index, does the possibility of recreation of a resource at that index break strict idempotency?
没有
A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request.
Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before the client is able to read the server's response. For example, if a client sends a PUT request and the underlying connection is closed before any response is received, then the client can establish a new connection and retry the idempotent request. It knows that repeating the request will have the same intended effect, even if the original request succeeded, though the response might differ.
注意：通用客户端可以重试请求；客户不需要了解您的特定实现。
It seems to me that for the original DELETE to be properly idempotent, the API should never create a new, different, resource with a previously used id, but I can't find a clear reference.
完全不是这样。考虑一个静态网站。网站所有者，您可以删除 foobar.html 吗？当然可以。你可以稍后重新创建它吗？当然。如果这是真的，那么远程编辑也应该如此。
如果远程编辑网站是正确的，那么其他任何 REST 也应该如此 API。统一接口的 点 是消费者不需要知道他们是在与文件系统、文档存储、数据库还是一些复杂的服务对话。 API 的工作是充当集成层，以便底层实现就像网络一样。
给定删除整数索引处资源的 DELETE 请求，在该索引处重新创建资源的可能性是否会破坏严格的幂等性？
例如对 /api/resource/123 发出的 DELETE 请求会删除 123 处的资源。然后会发出 post 请求，该请求会创建一个新资源，可以通过对同一 url 的 GET 请求检索该资源。
在我看来，要使原始 DELETE 正确地幂等，API 永远不应该使用以前使用过的 ID 创建一个新的、不同的资源，但我找不到明确的参考。
事实上，这与方法的幂等行为无关。 这就是命名资源的问题。因为如果资源从未存在过，则删除的行为与资源被删除后的行为完全相同。 是的，第二个请求将删除具有相同名称的新资源。 但是如果您遇到这个问题，只需创建一个唯一的资源名称。（例如 UUID） 您也可以尝试使用数据库索引。即使删除了键为“123”的条目 - 数据库也不会再次创建它。
Given a DELETE request that will delete resource at an integer index, does the possibility of recreation of a resource at that index break strict idempotency?
没有
A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request.
Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before the client is able to read the server's response. For example, if a client sends a PUT request and the underlying connection is closed before any response is received, then the client can establish a new connection and retry the idempotent request. It knows that repeating the request will have the same intended effect, even if the original request succeeded, though the response might differ.
注意：通用客户端可以重试请求；客户不需要了解您的特定实现。
It seems to me that for the original DELETE to be properly idempotent, the API should never create a new, different, resource with a previously used id, but I can't find a clear reference.
完全不是这样。考虑一个静态网站。网站所有者，您可以删除 foobar.html 吗？当然可以。你可以稍后重新创建它吗？当然。如果这是真的，那么远程编辑也应该如此。
如果远程编辑网站是正确的，那么其他任何 REST 也应该如此 API。统一接口的 点 是消费者不需要知道他们是在与文件系统、文档存储、数据库还是一些复杂的服务对话。 API 的工作是充当集成层，以便底层实现就像网络一样。