HTTP Methods Reference
Free online HTTP methods reference. No sign-up, no installation. Runs entirely in your browser.
HTTP Methods
Comparison Table
RESTful CRUD Operations
Example Requests
What are HTTP Methods?
HTTP methods (also called HTTP verbs or request methods) define the action you want to perform on a server resource. They are fundamental to the HTTP protocol and essential for building RESTful APIs. Each HTTP method has specific semantics that should be followed when designing web services.
The most commonly used methods are GET, POST, PUT, PATCH, and DELETE, which correspond to basic CRUD (Create, Read, Update, Delete) operations. HTTP also defines other methods like HEAD, OPTIONS, CONNECT, and TRACE, each with specialized use cases in web development and API design.
How to Use This Reference
Browse HTTP methods above by clicking each button to see detailed information including:
- Description: What the method does
- Safe: Whether the method modifies server state
- Idempotent: Whether repeated calls produce the same result
- Cacheable: Whether responses can be cached
- Request Body: Whether the method can include a message body
- Response Codes: Common HTTP status codes returned
- Use Cases: Practical REST API applications
Use the comparison table to quickly see differences. Check CRUD operations for standard database patterns. Review examples to see real HTTP message formats with copy functionality.
REST API Design Best Practices
Use the right method for the job: Always use the HTTP method that semantically matches your operation. Use PUT for full updates and PATCH for partial updates, not POST for everything.
Leverage idempotency: Idempotent methods (GET, PUT, DELETE) can be safely retried without unintended side effects. Design APIs so clients can safely retry failed requests without duplication concerns.
Return appropriate status codes: Match status codes to operation results (200 success, 201 created, 204 no content, 400 bad request, 404 not found).
Use safe methods for reads: Safe methods like GET and HEAD don't modify state and can be cached, prefetched, or retried safely by clients and proxies.
Include bodies only when needed: GET and DELETE typically don't include request bodies. Use POST or PATCH to send data in the message body.
Frequently Asked Questions
What's the difference between PUT and PATCH?
PUT replaces the entire resource with the data you send. Missing fields are deleted or nullified. PATCH partially updates a resource—only fields in the request are modified, others stay unchanged. For example, PATCH only the email field leaves name and phone intact, while PUT with just email would delete the other fields.
Why is GET considered "safe"?
GET is "safe" because it should never modify server data. Safe methods are read-only and can be called repeatedly without changing state. This allows browsers and proxies to cache GET requests, prefetch them, or retry them if the connection drops. If GET modified data, these optimizations would be dangerous.
What does "idempotent" mean in HTTP?
An idempotent method produces the same result no matter how many times you call it. GET, HEAD, PUT, and DELETE are idempotent—deleting a resource twice returns the same result. POST and PATCH are NOT idempotent because repeated calls produce different results (POST creates multiple resources, PATCH might apply changes differently each time).
When should I use CONNECT or TRACE?
CONNECT is rarely used—it establishes secure tunnels through HTTP proxies, primarily for HTTPS. TRACE is even rarer, used only for debugging to see what the server received. Most modern APIs never use these methods. Build REST APIs with GET, POST, PUT, PATCH, and DELETE instead.
Can GET requests have a request body?
Technically allowed, but strongly discouraged. HTTP semantics define GET as safe and cacheable. Many servers, proxies, and clients ignore or reject GET requests with bodies. If you need to send complex data for retrieval, use POST instead or pass data as URL query parameters.
What does a 201 Created status code mean?
A 201 response indicates a POST request successfully created a new resource. The response usually includes a Location header with the new resource's URL and the created resource in the response body. For example, POST /users might return 201 with Location: /users/123 and the user data.