幂等REST API

在REST API的上下文中,当生成多个相同的请求与生成单个请求具有相同的效果时 - 然后该REST API称为幂等

设计REST API时,必须意识到API使用者可能会犯错误。他们可以编写客户端代码,以便可以存在重复请求。这些重复请求可能是无意的以及有意的一些时间(例如由于超时或网络问题)。您必须以这样的方式设计容错API,使重复请求不会使系统不稳定。

幂等HTTP方法是一种HTTP方法,可以多次调用而不会产生不同的结果。如果只调用一次或十次调用该方法,则无关紧要。结果应该是一样的。它本质上意味着成功执行请求的结果与其执行次数无关。例如,在算术中,向数字加零是幂等操作。

如果您在设计API时遵循REST原则,那么您将拥有用于GET,PUT,DELETE,HEAD,OPTIONS和TRACE HTTP方法的自动幂等REST API。只有POSTAPI不是幂等的。

  1. POST 不是幂等的。
  2. GETPUTDELETEHEADOPTIONSTRACE是幂等。

让我们分析一下HTTP方法如何最终成为幂等 - 任何POST不是为什么。

HTTP POST

通常 - 不一定 - 使用POSTAPI在服务器上创建新资源。因此,当您调用相同的POST请求N次时,您将在服务器上拥有N个新资源。因此,POST不是幂等的

HTTP GET,HEAD,OPTIONS和TRACE

GETHEADOPTIONSTRACE方法永远不会改变服务器上的资源状态。它们纯粹用于在那个时间点检索资源表示或元数据。因此,调用多个请求将不会在服务器上进行任何写操作,因此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
SO Thread