Skip to content
TabBench

HTTP Method Reference

Compare HTTP methods by safety, idempotency, cacheability and request body, with REST usage, example requests and advice on PUT vs PATCH and POST vs GET.

Runs in your browser. Nothing you add is uploaded.

What the HTTP Method Reference does

The HTTP method on a request tells the server what you intend to do, and whether it is safe to repeat. Choosing carelessly causes real bugs: a GET that changes data gets triggered by crawlers, a POST retried after a timeout creates duplicates, a PUT that should have been a PATCH wipes fields. This reference, based on RFC 9110, sets out for every method whether it is safe, idempotent and cacheable, what a body means, which status codes to expect and how it maps to a REST API.

How to choose an HTTP method

  1. Start with the comparison table: read across a row to see whether a method is safe, idempotent and cacheable, and whether it carries a body.
  2. Select a method to see its purpose, the success codes to expect, the practical notes and an example request.
  3. If you are designing an API, read “Which one should I use?” for the usual choices: PUT or PATCH, PUT or POST, GET or POST.
  4. Follow a status-code chip to the lookup for the exact meaning of each response.
  5. Switch to the WebDAV tab if you work with file-sharing protocols.

The HTTP Method Reference runs entirely in your browser — nothing you enter is uploaded, stored, or logged.

When to use it

Designing a REST API

Map create, read, update and delete to POST, GET, PUT or PATCH and DELETE, and return the right status code for each.

Deciding what to retry

Clients and proxies may safely retry idempotent methods after a network failure. The reference shows which methods qualify.

Understanding a CORS preflight

Browsers send an OPTIONS request before a cross-origin call that uses PUT, PATCH, DELETE or custom headers. The OPTIONS entry explains what the server must answer.

Good to know

  • Never change data in response to a GET: prefetching, crawlers and link checkers will call it.
  • Make POST safe to retry by accepting an Idempotency-Key header and remembering its result.
  • Use PATCH with a defined format such as JSON Merge Patch, not an ad hoc body.
  • Disable TRACE on servers: it is a known security scanner finding.
  • A 405 response must include an Allow header listing the methods that do work.

Frequently asked questions

What does idempotent mean?

Sending the same request once or many times leaves the server in the same state. GET, PUT, DELETE, HEAD and OPTIONS are idempotent, which makes them safe to retry after a timeout. POST and PATCH generally are not.

Is a safe method the same as a secure one?

No. “Safe” means read-only: the method does not change anything on the server. It says nothing about encryption or authentication.

Can a GET request have a body?

The standard gives a body on GET no meaning, and many servers, proxies and libraries drop it. Use query parameters, or POST for large searches.

What is the difference between PUT and PATCH?

PUT replaces the whole resource with the body you send, so any field you leave out is removed. PATCH applies a partial change, so only the fields you send are touched.

Is DELETE idempotent if the second call returns 404?

Yes. Idempotent refers to the state of the server, not to the response: after the first DELETE the resource is gone, and deleting it again leaves it gone.

Is there a QUERY method?

A method for safe requests that carry a body, so large searches need not use POST, has been proposed by the IETF HTTP working group. Support is still limited, so check your server and client before depending on it.

Related tools