HTTP request methods define the action to be performed on a resource when making an HTTP request. Each method has defined semantics — whether it is safe (read-only), idempotent (repeatable without side effects), cacheable, and whether it carries a request or response body. Understanding these properties is essential for designing REST APIs, handling CORS, and implementing correct client and server behavior.
No methods match your search.
Quick Comparison Matrix
Safe = read-only, no side effects. Idempotent = same result if called multiple times.
| Method | Safe | Idempotent | Cacheable | Req Body | Res Body |
|---|
REST API — CRUD to HTTP Method Mapping
How standard CRUD operations map to HTTP methods in a RESTful API.
| CRUD Operation | HTTP Method | Example URL |
|---|---|---|
| Create | POST | POST /users |
| Read (list) | GET | GET /users |
| Read (single) | GET | GET /users/42 |
| Update (full) | PUT | PUT /users/42 |
| Update (partial) | PATCH | PATCH /users/42 |
| Delete | DELETE | DELETE /users/42 |
| Check existence | HEAD | HEAD /users/42 |
| Discover methods | OPTIONS | OPTIONS /users |
How to Use the HTTP Request Methods Reference
This HTTP request methods reference covers all nine methods defined by the HTTP specification — GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, TRACE, and CONNECT — with their semantic properties, idempotency rules, example curl commands, typical status codes, and real-world use cases. Use the search box or filter tabs to quickly find the method you need.
Step 1: Filter or search for a method
Type a method name or keyword (such as "idempotent", "safe", "CORS", or "CRUD") into the search box to filter in real time. Use the Safe, Idempotent, or Has Request Body tabs to quickly narrow down methods by their properties. All nine methods are visible by default.
Step 2: Expand a method card for full details
Click any method card to expand it. You will see a full description of the method's semantics, colored badges showing whether it is safe, idempotent, and cacheable, whether it accepts a request body and returns a response body, typical HTTP status codes, and a ready-to-use curl example. Click the copy button to copy the curl command directly to your clipboard.
Step 3: Check the comparison matrix
The Quick Comparison Matrix below the method cards provides a side-by-side view of all nine methods and their properties. Use it for a quick sanity check when designing an API or reviewing HTTP method semantics.
Understanding safe vs idempotent methods
A safe HTTP method does not change the state of the server — GET, HEAD, and OPTIONS are safe. Calling a safe method has no side effects, so clients and proxies can freely retry them. An idempotent method produces the same server state whether it is called once or many times — GET, PUT, DELETE, HEAD, and OPTIONS are idempotent. Note that DELETE is idempotent but not safe: the first call removes the resource, but subsequent calls (which may return 404) still leave the server in the same final state.
POST is neither safe nor idempotent — each call may create a new resource. PATCH is also not inherently idempotent, though it can be designed to be. When building fault-tolerant systems, prefer idempotent methods for operations that may need to be retried automatically.
HTTP methods and REST API design
The REST architectural style maps HTTP request methods to CRUD operations: GET for reading, POST for creating, PUT for full replacement, PATCH for partial update, and DELETE for removal. The CRUD mapping table at the bottom of this page shows exact URL patterns. HEAD is used to check whether a resource exists or has changed without downloading the body — useful for cache validation and polling. OPTIONS is used automatically by browsers as a CORS preflight check before cross-origin requests.
FAQ
Is this HTTP request methods reference free to use?
Yes, completely free. The reference runs entirely in your browser with no signup, no account, and no usage limits. All content is available offline once the page loads.
Is my data safe when using this tool?
Yes. Everything runs locally in your browser. No data is sent to any server. Your searches and browsing activity stay entirely on your device.
What is the difference between safe and idempotent HTTP methods?
A safe method does not modify server state — GET, HEAD, and OPTIONS are safe. An idempotent method produces the same result when called multiple times — GET, PUT, DELETE, HEAD, and OPTIONS are idempotent. All safe methods are also idempotent, but not all idempotent methods are safe (e.g., DELETE changes state but repeated calls have the same effect).
When should I use PUT vs PATCH?
Use PUT to replace an entire resource with a complete representation. Use PATCH to apply a partial update — only sending the fields you want to change. PUT is idempotent (calling it multiple times with the same body has the same effect), while PATCH may or may not be idempotent depending on how it is implemented.
Why does a GET request not have a request body?
The HTTP specification defines GET as a safe, idempotent retrieval method that carries request parameters via the URL query string, not the body. While technically possible to send a body with GET, most servers, proxies, and CDNs ignore it, and many HTTP clients don't support it. Use POST or PUT for sending request bodies.
What HTTP methods does a CORS preflight use?
CORS preflight requests use the OPTIONS method. Before sending a cross-origin request with a non-simple method or custom header, the browser automatically sends an OPTIONS request to check if the server allows it. The server responds with Access-Control-Allow-Methods and Access-Control-Allow-Headers to indicate what is permitted.
What is the difference between DELETE and a soft delete?
The HTTP DELETE method signals the intent to remove a resource — the server should delete or mark it as deleted. A 'soft delete' is an implementation detail where the server marks a record as inactive rather than physically removing it from the database, but still responds with 200 or 204. From the client's perspective, the resource is gone regardless of how the server implements it.
Which HTTP methods are cacheable?
GET and HEAD responses are cacheable by default when appropriate headers are present (Cache-Control, Expires, ETag). POST responses can be cached if the server includes explicit Cache-Control or Expires headers. PUT, PATCH, DELETE, OPTIONS, TRACE, and CONNECT are not cached.