HTTP Methods Reference & Sandbox

Explore RFC rules for HTTP request methods and compile, structure, and execute dynamic cURL tests inside a mock browser environment.

Method Specifications Matrix

Method	Safe	Idempotent	Req Body	Cacheable	Specification	Summary Description
GET	Yes	Yes	No	Yes	RFC 9110	Retrieve a representation of the target resource.
POST	No	No	Yes	No	RFC 9110	Submit data to be processed by the target resource.
PUT	No	Yes	Yes	No	RFC 9110	Replace the target resource with the request payload.
PATCH	No	No	Yes	No	RFC 5789	Apply partial modifications to a resource.
DELETE	No	Yes	Optional	No	RFC 9110	Remove the target resource.
HEAD	Yes	Yes	No	Yes	RFC 9110	Retrieve metadata headers identical to GET, without the response body.
OPTIONS	Yes	Yes	Optional	No	RFC 9110	Describe the communication options available for the target resource.
CONNECT	No	No	No	No	RFC 9110	Establish a transparent TCP/IP tunnel to the destination host.
TRACE	Yes	Yes	No	No	RFC 9110	Perform a message loop-back test along the path to the resource.

HTTP Request Configurator

Method

Target Endpoint URL

Headers (one per line)

Key: Value format

Method Details: GET

Use Case: Fetching web pages, API resources, or static assets.

Standard Response: 200 OK with body; 404 Not Found if resource is missing.

curl -X GET "https://api.example.com/users" \
  -H "Accept: application/json" \
  -H "Authorization: Bearer token_xyz123"

HTTP Request Methods Explained

HTTP request methods represent semantic actions executed on resource targets. Methods designated as Safe (such as GET or HEAD) must be read-only and never modify critical backend database entities.

Idempotent methods (e.g. PUT or DELETE) can be called sequentially multiple times without generating diverging system states. Using the sandbox, you can customize headers, request payloads, compile compliant cURL shells, and inspect raw HTTP/1.1 payloads.

Built and maintained by Meet Shah · Last updated 1 August 2026

What this tool is used for

Checking whether a method is safe, idempotent or cacheable.
Choosing between PUT and PATCH for an update.
Confirming which status codes a method conventionally returns.
Reading what a method you use rarely is actually for.
Settling a design discussion with the specification's properties.

Frequently Asked Questions

What does safe mean for a method?: That it is read-only from the client's point of view: GET, HEAD and OPTIONS should not change server state. Logging and analytics side effects are fine — what is not fine is a GET that deletes something, which crawlers and prefetchers will eventually trigger.
What is idempotency?: Applying a request many times leaves the same state as applying it once. PUT and DELETE qualify — deleting an already-deleted resource changes nothing further. POST does not, which is why a resubmitted form can create two records.
Why is PATCH not idempotent?: Because a patch document can express a relative change. `{"op":"add"}` on an array appends every time it runs. A patch that only sets absolute values happens to be idempotent, but the method carries no such guarantee.
When should I use PUT rather than POST?: PUT when the client decides the URI and is replacing the whole resource; POST when the server assigns the URI or the request is an action rather than a replacement. PUT with a partial body is the usual mistake — it should mean "make it exactly this".
What is OPTIONS actually used for?: Almost entirely CORS preflight. Before a cross-origin request with a non-simple method or header, the browser sends OPTIONS and reads the `Access-Control-Allow-*` response before deciding whether to send the real request.
Which methods can be cached?: GET and HEAD by default. POST responses are cacheable only with explicit freshness headers and rarely are in practice. This is why moving a read endpoint from GET to POST quietly removes every layer of caching in front of it.

Common errors and gotchas

Using GET for something that changes state, which caches, prefetchers and crawlers will then trigger.
Assuming POST is idempotent, which it is not — retries can duplicate.
Sending a body with GET or DELETE, which the specification permits ambiguously and proxies may drop.
Confusing PUT with PATCH, where one replaces the resource and the other modifies it.
Treating idempotent as meaning the same response, when it means the same effect.