HTTP Method Use Case Guide

Report an Issue

Help us improve by telling us what went wrong.

Embed this Tool

Customize and copy the embed code for your website.

Know Exactly When to Use GET, POST, PUT, PATCH, and DELETE

HTTP methods seem straightforward until you're designing an API and questions start piling up. Should updating a user profile be PUT or PATCH? Is DELETE truly idempotent? Can GET requests have a body? The HTTP Method Use Case Guide answers these questions definitively, providing clear explanations and real-world examples for every standard HTTP method so you can design APIs that are correct, predictable, and easy for other developers to consume.

RESTful API design depends on using HTTP methods according to their intended semantics. Misusing methods - like using POST for everything or PUT when PATCH is appropriate - leads to APIs that confuse consumers, break caching, and violate the principle of least surprise. The HTTP Method Use Case Guide ensures you choose the right method every time by explaining the semantics, safety guarantees, and idempotency properties of each one.

Methods Covered in This Guide

The guide covers all standard HTTP methods with depth. GET retrieves resources without side effects. POST creates new resources or triggers actions. PUT replaces a resource entirely. PATCH applies partial modifications. DELETE removes a resource. HEAD retrieves headers without the body. OPTIONS describes available methods (critical for CORS). TRACE and CONNECT round out the HTTP specification.

For each method, the guide explains its safety (does it modify server state?), idempotency (does repeating it produce the same result?), cacheability (can intermediaries cache the response?), and request body expectations (should it have one?). These properties are the foundation of correct API design and are frequently tested in technical interviews.

The PUT vs PATCH Debate Settled

This is probably the most common point of confusion in REST API design. The guide explains it clearly: PUT replaces the entire resource. If you PUT a user object with only the name field, every other field becomes null or default. PATCH updates only the specified fields. Sending a PATCH with just the name field leaves all other fields untouched. The guide provides JSON examples for both, making the difference impossible to misunderstand.

Who Needs This Guide?

Backend developers designing new APIs consult this guide during the planning phase to ensure their endpoint design follows established conventions. When a colleague asks why you chose PATCH over PUT for a particular endpoint, you can point to the specific semantic distinction documented here.

Frontend developers consuming APIs benefit from understanding method semantics so they can predict behavior, implement proper error handling, and debug issues more effectively. Knowing that a PUT should be idempotent helps you understand why retrying a failed PUT is safe but retrying a failed POST might create duplicates.

API reviewers and architects use the guide as a shared standard during design reviews. Rather than relying on tribal knowledge or individual interpretation of the HTTP spec, the team references a common document that settles debates quickly.

Students and junior developers building their first APIs use the guide to internalize best practices before they develop bad habits. It's much easier to design correctly from the start than to refactor a misdesigned API later.

Real-World Decision Scenarios

You're building an e-commerce API. Should the checkout action be POST or PUT? It's POST - it creates a new order and triggers irreversible side effects. Should the cancel order action be DELETE or POST? The guide explains why POST is typically better here (it's not truly deleting a resource, it's changing its state). Should fetching order history be GET or POST? GET - it's a retrieval with no side effects. But what if the filter criteria are complex? The guide discusses when POST-based search endpoints are justified despite GET being the semantic default for retrieval.

Tips for Better API Design

Use method semantics to inform your URL structure. If you need a verb in the URL (like /users/123/activate), you're probably using POST - actions that don't map to CRUD naturally belong there. Keep GET requests free of side effects - this isn't just convention, it's what allows browsers, CDNs, and proxies to cache responses. Remember that 405 Method Not Allowed is the proper response when a valid URL receives an unsupported method, and use OPTIONS to advertise which methods are available.

The HTTP Method Use Case Guide runs in your browser and is always accessible. Bookmark it as your API design companion and save yourself from second-guessing method choices ever again.