butterfly/kb
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
be9d1ccd3c
kb/data/developer.mozilla.org/en-US/docs/Glossary/Idempotent-0.md

13 KiB
Raw Blame History

title chunk source category tags date_saved instance
Idempotent - Glossary | MDN 1/3 https://developer.mozilla.org/en-US/docs/Glossary/Idempotent reference web, html, css, javascript, documentation 2026-05-05T05:34:55.149014+00:00 kb-cron

MDN HTML HTML: Markup language

HTML reference

HTML guides

Markup languages

CSS CSS: Styling language

CSS reference

CSS guides

Layout cookbook

JavaScriptJS JavaScript: Scripting language

JS reference

JS guides

Web APIs Web APIs: Programming interfaces

Web API reference

Web API guides

All All web technology

Technologies

Topics

Learn Learn web development

Frontend developer course

Learn HTML

Learn CSS

Learn JavaScript

Tools Discover our tools

About Get to know MDN better

Blog

  1. Glossary
  2. Idempotent

Idempotent

An HTTP method is idempotent if the intended effect on the server of making a single request is the same as the effect of making several identical requests. The HTTP specification defines several HTTP methods and their semantics, which includes whether they are idempotent or not. All safe methods are idempotent, as well as PUT and DELETE. The POST and PATCH methods are not guaranteed to be idempotent. A client can safely retry a request that uses an idempotent method, for example, in cases where there is doubt as to whether the request reached the server. If multiple identical requests happen to reach the server, as long as the method is idempotent, no harm is done. The HTTP specification only defines idempotency in terms of the intended effect of the client on the server. For example, a POST request intends to send data to the server, whereas a DELETE request intends to delete a resource on the server. In practice, it falls to the server to make sure the routes it exposes adhere to these semantics. Note: While servers are very much encouraged to adhere to the semantics laid out by the HTTP specification, the spec does not mandate it. Nothing is preventing a server in the wild from exposing a non-idempotent endpoint under an idempotent HTTP method, although clients may be surprised. Also, bear in mind:

  • A request with an idempotent method does not necessarily mean that the request has no side effects on the server, only that the client intended none: For example, the server may log the time each request is received.
  • The response returned by each request may differ: for example, the first call of a DELETE will likely return a 200, while successive ones will likely return a 404.

In this article

Examples

GET /pageX HTTP/1.1 is idempotent, because it is a safe (read-only) method. Successive calls may return different data to the client, if the data on the server was updated in the meantime. POST /add_row HTTP/1.1 is not idempotent; if it is called several times, it adds several rows: DELETE /idX/delete HTTP/1.1 is idempotent, even if the returned status code may change between requests:

See also