No Login Data Private Local Save

HTTP Methods Cheatsheet - Online GET POST PUT DELETE Guide

Developer Tools Reference cheatsheet HTTP methods REST
48
0
0
0
HTTP Methods Reference Updated for 2024 • RESTful API Design

HTTP Methods Cheatsheet

A comprehensive guide to HTTP request methods — GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS, TRACE, and CONNECT. Learn when to use each method, their properties, and RESTful API best practices.

Methods
9
Safe
4
Idempotent
6
Cacheable
3
Body Allowed
4
REST Core
5
Select a Method
GET
GET
Retrieve a resource
Safe Idempotent Cacheable
POST
POST
Create a new resource
Not Safe Not Idempotent
PUT
PUT
Replace / upsert a resource
Not Safe Idempotent
DEL
DELETE
Remove a resource
Not Safe Idempotent
PAT
PATCH
Partial update
Not Safe Not Idempotent*
HED
HEAD
Get headers only (no body)
Safe Idempotent Cacheable
OPT
OPTIONS
Discover allowed methods
Safe Idempotent
TRC
TRACE
Diagnostic loop-back test
Safe Idempotent
CON
CONNECT
Establish a tunnel
Not Safe
GET

GET Method

Retrieve a representation of a resource

The GET method is used to retrieve data from a specified resource. It is the most common HTTP method and forms the backbone of data retrieval on the web. GET requests should only retrieve data and have no other side effects — they are considered safe and idempotent.

GET /api/users/123 HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer token_here
Key Properties
Safe — No side effects Idempotent — Multiple identical requests = same result Cacheable — Responses can be cached
Request Body: ❌ Not recommended | Success Code: 200 OK | Common Use: Fetching web pages, API data retrieval, search queries

HTTP Status Codes Quick Reference

Every HTTP response includes a status code. Here are the most commonly used codes you'll encounter when working with RESTful APIs.

2xx Success
200OK — Request succeeded
201Created — Resource created
202Accepted — Processing
204No Content — Success, no body
3xx Redirection
301Moved Permanently
302Found — Temporary redirect
304Not Modified — Use cache
307Temporary Redirect (preserve method)
4xx Client Errors
400Bad Request — Malformed syntax
401Unauthorized — Authentication required
403Forbidden — No permission
404Not Found — Resource doesn't exist
405Method Not Allowed
409Conflict — State conflict
422Unprocessable Entity
429Too Many Requests — Rate limit
5xx Server Errors
500Internal Server Error
502Bad Gateway
503Service Unavailable
504Gateway Timeout

RESTful API Endpoint Conventions

Action Method Endpoint Example Response
List all GET /users /api/users 200 + array
Get one GET /users/{id} /api/users/42 200 + object
Create POST /users /api/users 201 + object
Full update PUT /users/{id} /api/users/42 200 / 204
Partial update PATCH /users/{id} /api/users/42 200 / 204
Delete DELETE /users/{id} /api/users/42 200 / 204
Nested resource GET /users/{id}/posts /api/users/42/posts 200 + array
HTTP Methods Decision Flow
Start: Need to interact with /api/resource Read data? → GET Create new? → POST Replace all? → PUT Change part? → PATCH Remove? → DELETE

Frequently Asked Questions

Common questions about HTTP methods, RESTful API design, and best practices.

PUT replaces the entire resource with the request payload. If a field is omitted in a PUT request, it's assumed the field should be removed or reset to default. PATCH applies a partial update — only the fields specified in the request body are modified, and all other fields remain unchanged. Use PUT for full replacements and PATCH for selective field updates. PUT is always idempotent; PATCH may or may not be idempotent depending on the implementation.

An idempotent HTTP method produces the same result on the server regardless of how many times it is executed. For example, sending the same DELETE request twice still results in the resource being deleted (the second call returns 404, but the server state is the same as after the first call). GET, HEAD, PUT, DELETE, OPTIONS, and TRACE are idempotent. POST is not idempotent — sending the same POST request twice creates two separate resources.

A safe HTTP method is one that does not modify the server's state — it's read-only. Safe methods are: GET, HEAD, OPTIONS, and TRACE. Safe methods can be called without any risk of changing data, making them ideal for crawling, link checking, and caching. Note that even safe methods can have side effects like logging or analytics tracking, but they should never alter the resource itself.

Technically, the HTTP/1.1 specification does not explicitly forbid sending a body with a GET request. However, it is strongly discouraged and most servers, proxies, and libraries ignore or reject GET request bodies. Many frameworks strip the body from GET requests entirely. If you need to send complex query parameters, use URL query strings or consider using POST for search endpoints.

Use POST when the server determines the resource's URI (e.g., POST /users → server assigns ID and returns /users/123). Use PUT when the client specifies the exact URI (e.g., PUT /users/123 — the client knows the ID). POST is for creating subordinate resources where the server controls the naming; PUT is for upsert operations where the client controls the resource identifier.

CORS (Cross-Origin Resource Sharing) is a browser security mechanism that restricts cross-origin HTTP requests. When a browser makes a cross-origin request that is not "simple" (e.g., uses custom headers or methods other than GET/POST/HEAD), it first sends an OPTIONS preflight request to check if the server allows the actual request. The server responds with headers like Access-Control-Allow-Methods and Access-Control-Allow-Origin indicating what's permitted.

Common practice is to return 200 OK with a response body (e.g., the deleted resource) or 204 No Content with no body. If the resource doesn't exist, you can return 404 Not Found, though since DELETE is idempotent, some APIs return 204 even if the resource was already deleted. For asynchronous deletions, 202 Accepted is appropriate.

TRACE is disabled due to Cross-Site Tracing (XST) attacks. Attackers can use TRACE to echo back HTTP headers that may contain sensitive information like authentication cookies or tokens. Since TRACE reflects the entire request, it can be exploited to bypass the HttpOnly cookie flag. Most modern web servers (Apache, Nginx, IIS) disable TRACE by default for security reasons.

The standard CRUD-to-HTTP mapping is: Create → POST (create a new resource), Read → GET (retrieve one or many resources), Update → PUT or PATCH (PUT for full replacement, PATCH for partial updates), and Delete → DELETE (remove a resource). This pattern forms the foundation of RESTful API design and is widely adopted across the industry.

Yes, using POST for complex search queries is a common and accepted practice. When search parameters are too long or complex for URL query strings, or when you need to send a JSON body with nested filters, POST to an endpoint like /api/search is appropriate. Some APIs use POST /api/users/search with a JSON body containing filter criteria. While GET is ideal for simple queries, POST is acceptable for complex search operations.

Best Practices

Use Plural Nouns

Use /users not /user. Consistency makes your API predictable and intuitive for developers.

Version Your API

Prefix endpoints with /v1/ or use header-based versioning to avoid breaking existing clients.

Return Proper Status Codes

Always return the appropriate HTTP status code. Don't return 200 OK with an error message in the body.

Use Proper HTTP Headers

Set Content-Type, Accept, and caching headers. Use Location header for 201 responses.

🔧 Related Tools