HTTP Methods Reference

Complete reference for all 9 HTTP methods — descriptions, idempotency, safety, request body, use cases, and examples.

9 HTTP methods

Quick Comparison Table

Method Safe Idempotent Request Body Response Body Cacheable

Understanding HTTP Methods

HTTP methods (also called HTTP verbs) define the action to be performed on a resource identified by a URL. They are a fundamental part of the HTTP protocol and form the backbone of RESTful API design. Choosing the right method is not just about convention — it affects caching behavior, browser handling, security, and how intermediate proxies treat requests.

Safe vs. Unsafe Methods

A "safe" HTTP method is one that does not modify server state. GET, HEAD, OPTIONS, and TRACE are considered safe — they are read-only operations. POST, PUT, PATCH, DELETE, and CONNECT are unsafe because they can modify or delete data. Browsers and caches treat safe methods more liberally, allowing them to be repeated automatically (for example, when reloading a page).

Idempotency Explained

An idempotent method produces the same result regardless of how many times it is called with the same input. GET, PUT, DELETE, HEAD, OPTIONS, and TRACE are all idempotent. POST is the notable exception — submitting the same form twice creates two records. PATCH is technically not required to be idempotent by the spec, though well-designed APIs often make it so. Idempotency is critical for retry logic in distributed systems: if a DELETE request times out, you can safely retry it without worrying about double-deleting.

REST and HTTP Methods

RESTful APIs use HTTP methods to represent CRUD operations: GET (Read), POST (Create), PUT/PATCH (Update), DELETE (Delete). A well-designed REST API maps these operations to resource URLs: GET /users/123 retrieves a user, POST /users creates one, PUT /users/123 replaces it, PATCH /users/123 partially updates it, and DELETE /users/123 removes it.

CORS Preflight and OPTIONS

Modern browsers enforce CORS (Cross-Origin Resource Sharing) policy by sending an OPTIONS preflight request before any cross-origin POST, PUT, PATCH, or DELETE request. The server must respond with the appropriate Access-Control-Allow-* headers, or the actual request will be blocked. Understanding OPTIONS is essential for debugging CORS errors in web applications.

HEAD for Metadata

HEAD is often overlooked but extremely useful. It returns the same headers as a GET request without the body, making it ideal for checking if a resource exists, checking its Content-Type, or checking its Last-Modified date without downloading the full response. Web crawlers, link checkers, and download managers use HEAD extensively.

Frequently Asked Questions

PUT replaces the entire resource with the request body. If you omit a field, it is deleted. PATCH applies a partial update — only the fields in the request body are changed. Use PUT for full replacements, PATCH for partial updates.
An idempotent method produces the same result no matter how many times you call it. GET, PUT, DELETE, HEAD, OPTIONS, and TRACE are idempotent. POST and PATCH are not — calling POST twice creates two resources.
GET retrieves data without changing state; parameters go in the URL. POST submits data that changes state; parameters go in the body. GET can be cached and bookmarked; POST cannot.
Use DELETE for hard deletes. For soft deletes (keeping audit trail), use PATCH to set an 'active' or 'deleted_at' field. Many production systems prefer soft deletes for data recovery and referential integrity.
OPTIONS returns the allowed HTTP methods for a URL. It is most commonly used in CORS preflight requests — browsers automatically send OPTIONS before cross-origin POST/PUT/DELETE to check if the server permits it.