HTTP Methods Overview

When your browser asks "Are you sure you want to resubmit this form?" it's not being annoying. It's asking because the original request made no promise about what happens if you do it twice. Maybe it charges your card again. Maybe it creates a duplicate order. The browser doesn't know—and that uncertainty is baked into the HTTP method that was used.

HTTP methods are promises about consequences. They're contracts between client and server about what will happen when a request is made. GET promises to only look. POST warns that something will change. The entire architecture of the web—caching, retries, prefetching, that refresh warning—depends on these promises being kept.

The Promise of GET

GET says: "I will only look. Nothing will change because of this request."

When you type a URL or click a link, your browser sends a GET request. The server returns data—a webpage, an image, JSON—without modifying anything. This promise enables everything that makes the web fast and reliable:

• Caching works because the response won't be different if you ask again
• Prefetching works because loading a link early won't trigger unwanted actions
• Bookmarks work because the URL captures everything needed to repeat the request
• The back button works because revisiting won't accidentally resubmit something

GET requests can include parameters in the URL (?search=query&page=2), but those parameters should only filter or specify what you're looking at, never trigger changes.

Breaking GET's promise—making a GET request that modifies data—is one of the most dangerous mistakes in web development. Google's web crawler once bankrupted a company by following "delete" links that were implemented as GETs.

The Warning of POST

POST says: "Something will change. I'm not promising what happens if you do this twice."

When you submit a form, upload a file, or create an account, you're making a POST request. Data goes in the request body (not the URL), and the server typically creates something, processes something, or triggers some action.

POST makes no promise about repetition. Submit a payment form twice? You might be charged twice. Create an account twice? You might get duplicate records. This is why:

• Browsers warn before refreshing POST results
• The back button feels dangerous after checkout
• API clients need explicit retry logic for POST requests

POST is the honest method. It admits that actions have consequences and those consequences might not be reversible or repeatable.

PUT: The Complete Replacement

PUT says: "Here is exactly what this resource should be. Replace everything with this."

Unlike POST which creates or triggers, PUT replaces. You're not asking the server to figure out what changed—you're handing it the complete new state. Update a user profile with PUT and you send every field, even unchanged ones.

PUT makes a powerful promise: doing it twice has the same effect as doing it once. If the first request succeeds, the second request just confirms the same state. If the first request fails mysteriously, you can safely retry. This property—idempotency—makes PUT invaluable for reliable systems.

PATCH: The Partial Update

PATCH says: "Change just these specific things."

Where PUT sends the whole resource, PATCH sends only the changes. Update just an email address without touching name, phone, or preferences. This is efficient for large resources and practical when clients don't have access to all fields.

PATCH's promise is weaker than PUT's. Whether repeating a PATCH is safe depends on what the patch says. "Set email to X" is safe to repeat. "Increment counter by 1" is not. The method itself makes no guarantee.

DELETE: The Removal

DELETE says: "Remove this resource."

DELETE to /api/users/123 removes that user. Subsequent GETs return 404 Not Found. Simple.

Like PUT, DELETE is idempotent. Delete something twice? It's still deleted. This makes DELETE safe to retry when network errors leave you uncertain whether the first request succeeded.

Many systems implement "soft deletes" where resources are marked deleted rather than destroyed—preserving data for recovery or audits—but from the client's perspective, the resource is gone.

HEAD and OPTIONS: The Metadata Methods

HEAD says: "Tell me about this resource without sending it."

HEAD is GET without the body. Check if a file exists, see when it was modified, learn how large it is—all without downloading. Monitoring systems use HEAD to verify servers are responding without transferring full pages.

OPTIONS says: "What can I do here?"

OPTIONS asks the server what methods are allowed. Browsers send OPTIONS automatically as "preflight" checks before certain cross-origin requests, asking permission before attempting the real request.

Safe Methods: The Promise Not to Change Anything

GET, HEAD, and OPTIONS are safe methods. They promise not to modify server state. This promise enables:

• Aggressive caching by proxies and CDNs
• Prefetching by browsers guessing what you'll click next
• Web crawlers exploring your site without fear
• Retry logic that doesn't worry about duplication

POST, PUT, PATCH, and DELETE are unsafe methods. They might change things. Servers should authenticate them carefully. Clients should not repeat them carelessly.

Idempotent Methods: The Promise About Repetition

GET, HEAD, OPTIONS, PUT, and DELETE are idempotent. Once is the same as twice. This promise enables:

• Automatic retries when network errors occur
• Load balancers that can resend requests to healthy servers
• Clients that don't need to track whether their request succeeded

POST is explicitly not idempotent. The method itself warns you: "I can't promise what happens twice." PATCH is technically non-idempotent, though many implementations design their patches to be safe to repeat.

RESTful Conventions: Methods as a Language

REST APIs use HTTP methods to create predictable interfaces:

Once you understand this pattern, APIs become self-documenting. The method tells you what kind of action. The URL tells you what resource. The combination tells you what will happen.

The Contracts That Hold the Web Together

HTTP methods are not arbitrary labels. They're promises that the entire web relies on.

GET's promise to only look is why caching works, why prefetching is safe, why the back button doesn't accidentally resubmit your order. POST's honest warning about consequences is why browsers interrupt you before refreshing a checkout page. PUT and DELETE's idempotency is why distributed systems can retry failed requests without fear.

When these promises are kept, the web works smoothly. When they're broken—when a GET deletes something, when a POST is assumed to be safe to retry—things break in ways that are hard to debug and sometimes impossible to undo.

The methods are simple. The promises they encode are what matter.