在REST API的上下文中，当生成多个一样的请求与生成单个请求具有一样的效果时 – 然后该REST API称为幂等。
设计REST API时，必须意识到API使用者可能会犯错误。他们可以编写客户端代码，以便可以存在重复请求。这些重复请求可能是无意的以及有意的一些时间（例如由于超时或网络问题）。您必须以这样的方式设计容错API，使重复请求不会使系统不稳定。
幂等HTTP方法是一种HTTP方法，可以多次调用而不会产生不同的结果。如果只调用一次或十次调用该方法，则无关紧要。结果应该是一样的。它本质上意味着成功执行请求的结果与其执行次数无关。例如，在算术中，向数字加零是幂等操作。
如果您在设计API时遵循REST原则，那么您将拥有用于GET，PUT，DELETE，HEAD，OPTIONS和TRACE HTTP方法的自动幂等REST API。只有POSTAPI不是幂等的。
- POST 不是幂等的。
- GET，PUT，DELETE，HEAD，OPTIONS和TRACE是幂等。
让我们分析一下HTTP方法如何最终成为幂等 – 任何POST不是为什么。
HTTP POST
一般 – 不必定 – 使用POSTAPI在服务器上创建新资源。因此，当您调用一样的POST请求N次时，您将在服务器上拥有N个新资源。因此，POST不是幂等的。
HTTP GET，HEAD，OPTIONS和TRACE
GET，HEAD，OPTIONS和TRACE方法永远不会改变服务器上的资源状态。它们纯粹用于在那个时间点检索资源表明或元数据。因此，调用多个请求将不会在服务器上进行任何写操作，因此GET，HEAD，OPTIONS和TRACE是幂等的。
HTTP PUT
一般 – 不必定 – 使用PUTAPI来更新资源状态。如果您调用PUTAPI N次，则第一个请求将更新资源; 休憩N-1请求将一次又一次地覆盖一样的资源状态 – 实际上不会改变任何东西。因此，PUT是幂等的。
HTTP DELETE
当您调用N个类似的DELETE请求时，第一个请求将删除资源，响应将是200 (OK)或204 (No Content)。其他N-1请求将返回404 (Not Found)。显然，响应与第一个请求不同，但服务器端的任何资源都没有状态更改，由于原始资源已被删除。因此，DELETE是幂等的。
请记住，如果某些系统可能有这样的DELETE API：
DELETE /item/last在上述情况下，调用N次操作将删除N个资源 – 因此DELETE在这种情况下不是幂等的。在这种情况下，一个好的提议可能是将上面的API更改为POST – 由于POST不是幂等的。
POST /item/last目前，这更接近HTTP规范 – 因此更符合REST。
参考文献：
- Rfc 2616（https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html）；
- SO Thread（https://stackoverflow.com/questions/7016785/is-put-delete-idempotent-with-rest-automatic）。
- 最新
- 最热
只看作者