HTTP methods (also called verbs) define the type of action a client wants to perform on a resource when communicating with a web server. Understanding them is fundamental to building and consuming APIs and web applications.
HTTP methods are standardized keywords sent in the request line of an HTTP message to indicate the desired operation on a given resource. Common methods include GET, POST, PUT, PATCH, DELETE, HEAD, and OPTIONS. They are defined by the HTTP specification (RFC 7231 and related RFCs) and form the backbone of RESTful API design. Every HTTP request must include exactly one method.
GET retrieves a resource from the server without modifying any data; it is safe and idempotent, meaning repeated calls produce the same result and cause no side effects. POST submits data to the server to create a new resource or trigger a process, and it is neither safe nor idempotent. GET requests pass data via URL query parameters, while POST sends data in the request body, making POST better suited for sensitive or large payloads. Browsers use these two methods natively in HTML forms.
PUT replaces an entire resource at a given URL with the data provided; if the resource does not exist, many implementations will create it. PATCH applies a partial update, sending only the fields that need to change rather than the full representation, making it more bandwidth-efficient. DELETE removes the specified resource from the server and is idempotent — deleting the same resource multiple times results in the same end state (it no longer exists). These three methods are the core of CRUD-style REST APIs alongside GET and POST.
HEAD works exactly like GET but instructs the server to return only the response headers, not the body; it is useful for checking if a resource exists or reading metadata like content length before downloading. OPTIONS asks the server which HTTP methods and headers are supported for a given URL, and is automatically issued by browsers as a CORS preflight request before cross-origin calls. Correctly handling OPTIONS is essential for enabling cross-origin API access from browser clients.
A method is considered safe if it does not alter server state (GET and HEAD are safe). A method is idempotent if making the same request multiple times produces the same server state as making it once (GET, HEAD, PUT, DELETE, and OPTIONS are idempotent; POST and PATCH generally are not). These properties matter for caching, retry logic, and API client design — clients can safely retry idempotent requests on network failure. Confusing safety and idempotency is a common source of subtle bugs in distributed systems.
Always use the semantically correct method for each operation — using GET to delete data, for example, breaks caching, browser history, and link-prefetching assumptions. Never put sensitive data such as passwords or tokens in a GET URL, because URLs are logged by servers, proxies, and browsers. When designing REST APIs, prefer PATCH over PUT for partial updates to avoid accidentally clearing fields the client did not intend to change. Ensure your server returns appropriate status codes (200, 201, 204, 404, 405) aligned with the method used so clients can handle responses correctly.
© RM Full Stack & AI Engineer · All guides · Roadmaps · Open the app