9 of 9
vs
Different safetyDifferent idempotence
- GET is safe, POST is not safe.
- GET is idempotent, POST is not idempotent.
- GET does not take a body, POST takes a body.
What it does
The HTTP Methods Reference is a quick-lookup table for the nine HTTP request methods (RFC 9110). For each method it shows the four properties that matter most in API design - safe, idempotent, cacheable, and takes a body - plus a plain-English description and its typical use. Search, filter by property, click a method for the full entry, and compare any two methods to see exactly where their semantics differ.
How to use it
- Search by method name or meaning (e.g.
patch,partial). - Toggle the Safe / Idempotent / Cacheable filters to narrow the list.
- Click a method to read its full description and typical use cases.
- Use Compare two methods (e.g. PUT vs PATCH) to see the semantic differences.
Examples
GET
Safe, idempotent, cacheable; retrieves a resource without changing it.PUT vs PATCH
Both modify a resource, but only PUT is idempotent (PATCH can have different effects when repeated).POST vs PUT
POST creates under a collection (server picks the URL, not idempotent); PUT puts a resource at a known URL (idempotent).Good to know
- Safe vs idempotent: safe means “no server state change”; idempotent means “repeating the call has the same effect as one”. All safe methods are idempotent, but not vice-versa (PUT and DELETE are idempotent but not safe).
- Source: property flags follow RFC 9110 / RFC 9111 and the MDN reference.
POSTis marked cacheable per the spec, though caches rarely store POST responses without explicit directives. - Related tools: HTTP Status Codes, JSON Formatter, URL Encoder.