HTTP Methods: GET, POST, and Friends

Every time you open a web page, submit a form, or tap “like” on a photo, your browser quietly sends a little message to a server. That message always starts with one short word: a verb. It might say GET, or POST, or DELETE. This word is the HTTP method, and it tells the server what kind of action you want to perform.

Think of it like ordering at a restaurant. The dish you want matters, but so does how you ask: are you asking to see the menu, place an order, change an order you already made, or cancel it entirely? Same restaurant, very different intentions. HTTP methods are exactly that set of intentions, written down in a way both browsers and servers agree on.

In this article we’ll walk through every method a beginner needs to know, what each one is for, and two important words that describe how they behave: safe and idempotent. No prior experience required.

What is an HTTP method, really?

HTTP (HyperText Transfer Protocol) is the language browsers and servers use to talk to each other. A single conversation has two parts: the browser sends a request, and the server sends back a response.

Every request begins with a line that names the method and the address you’re talking to. Here’s roughly what one looks like:

GET /articles/http-methods HTTP/1.1
Host: blog.acy-partner.com

That first word, GET, is the method. The rest tells the server which thing you mean (the path) and over which version of the protocol. You can picture the whole exchange like this:

  ┌──────────┐    GET /articles    ┌──────────┐
  │ Browser  │  ───────────────▶   │  Server  │
  │ (client) │                     │          │
  │          │  ◀───────────────   │          │
  └──────────┘    200 OK + page    └──────────┘

The method is the server’s first clue about your intention. A well-behaved server treats a GET very differently from a DELETE, even if both point at the same address. So let’s meet the methods one by one.

GET — reading things

GET is the method you use the most, even though you rarely notice it. Every time you visit a page, click a link, or load an image, your browser sends a GET. Its job is simple: fetch something and bring it back. It reads; it does not change anything.

Because GET only reads, it’s the gentlest of all the methods. You can refresh a page a hundred times and nothing on the server should break. That property is so important it has a name, which we’ll get to shortly.

GET /products/42 HTTP/1.1
Host: shop.example.com

One rule worth remembering: a GET request should not carry a meaningful body of data. If you need to send information to be stored, that’s a different job — and a different method.

POST — sending and creating

When you fill in a sign-up form, write a comment, or upload a photo, your browser usually sends a POST. This method submits data to the server so it can do something with it: create a new account, save a comment, process a payment.

Unlike GET, a POST carries a body — the actual data you’re sending. That data is often formatted as JSON, a simple text format for structured information:

POST /comments HTTP/1.1
Host: blog.acy-partner.com
Content-Type: application/json

{
  "author": "Jane Doe",
  "text": "Great explanation, thanks!"
}

The key idea: POST usually creates something new or triggers an action. If you submit the same form twice, you’ll often end up with two records — two comments, two orders. That’s the natural behavior, and later we’ll see why it matters.

PUT and PATCH — updating things

Sometimes you don’t want to create something new; you want to change something that already exists. Updating your profile, editing a comment, renaming a file. Two methods handle this: PUT and PATCH. They sound similar but differ in one neat way.

PUT — replace the whole thing

PUT says: “here is the complete, new version of this resource — replace what you have with this.” You send the entire object, not just the bits that changed.

PUT /users/7 HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "John Doe",
  "email": "john@example.com",
  "role": "editor"
}

If you only include the name and forget the email, a strict server may treat the missing email as “blank” — because PUT means replace everything.

PATCH — change just a piece

PATCH is the more surgical option: “here is only the part I want to change; leave everything else alone.” You send just the fields that differ.

PATCH /users/7 HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "role": "admin"
}

This updates the role and nothing else. As a rule of thumb: reach for PUT when you’re sending a complete replacement, and PATCH when you’re nudging one or two fields.

DELETE — removing things

DELETE does exactly what the name promises: it asks the server to remove a resource. Deleting a comment, removing an item from a cart, closing an account.

DELETE /comments/91 HTTP/1.1
Host: blog.acy-partner.com

There’s no body needed — the address already says what to delete. And here’s a subtle, comforting detail: if you send the same DELETE twice, the second one doesn’t break anything. The resource is already gone, so the result is the same. Hold that thought; it’s about to become a named concept.

HEAD and OPTIONS — the quiet helpers

Two more methods exist that you’ll rarely send by hand, but they’re worth knowing because they keep the web running smoothly behind the scenes.

HEAD works exactly like GET, with one difference: the server sends back only the headers, not the actual content. Headers are the small bits of metadata about a response — its size, type, and last-modified date, for example. Why ask for just the headers? To check something cheaply. A browser might use HEAD to ask “has this file changed since I last downloaded it?” without re-downloading the whole thing.

OPTIONS asks the server: “what am I allowed to do here, and what are the rules?” It’s like knocking on a door to ask which keys work before you try them. Browsers send OPTIONS automatically in certain situations — for example, when a page on one website wants to talk to an API on another — as a kind of permission check.

  Browser:  OPTIONS /data  →  "What can I do here?"
  Server:   Allow: GET, POST, OPTIONS

You almost never write these yourself, but now you’ll recognize them when they appear in your browser’s network tools.

Safe and idempotent — two words that explain a lot

Two terms come up constantly when people discuss HTTP methods. They sound technical, but the ideas are genuinely simple once you slow down.

Safe means the method doesn’t change anything on the server — it only reads. Visiting a page should never accidentally delete your account, and that’s because GET is safe. Reading the menu doesn’t place an order.

Idempotent is a longer word for a tidy idea: doing it once or doing it many times gives the same end result. Imagine a light switch labeled “OFF.” Press it once and the light is off. Press it five more times — still off. Nothing new happens after the first press. That’s idempotent.

DELETE is idempotent: delete a comment, and it’s gone; ask again, and it’s still gone — same final state. PUT is idempotent too: replacing a user with the same data ten times leaves the user looking identical to replacing it once.

POST, on the other hand, is usually not idempotent. Submit a payment form twice and you might be charged twice. This is exactly why websites warn “do not refresh this page” after a checkout — they’re protecting you from sending the same POST again.

Here’s the whole family in one table:

Why the right method matters

You might wonder: if a server can read or write data either way, why be fussy about the verb? Because the rest of the web relies on these promises.

Browsers, search engines, and intermediate systems all assume GET is safe. A search engine will happily follow thousands of GET links to read your site, but it should never follow a link that secretly deletes data. That’s a real bug pattern from years ago: people put “delete” actions behind plain links, a web crawler came along clicking every link, and content vanished. Using the correct method — DELETE for deleting, POST for actions — keeps these automatic systems from doing damage.

Choosing the right verb also makes your system easier to understand. When another developer sees DELETE /orders/5, they know precisely what it does without reading a single line of your code. The method itself documents the intention.

Where to go from here

You’ve now met the core HTTP methods and the two properties that describe their behavior. This is the protocol-level view: what each verb means and how it’s supposed to behave on the wire. It’s the foundation everything else sits on.

The natural next step is seeing how these methods get put to work when designing real web APIs — the world of REST, where GET, POST, PUT, PATCH, and DELETE map onto reading and writing structured resources. That’s a backend topic, and it builds directly on what you’ve learned here.

For now, try opening your browser’s developer tools, switching to the Network tab, and reloading a page. You’ll see a stream of requests, each tagged with its method. Watch the GETs fly by as the page loads, and the occasional POST when you submit something. The vocabulary you just learned is right there, working in plain sight.

Recap

• An HTTP method is the verb at the start of every request that tells the server your intention.
• GET reads, POST sends or creates, PUT replaces fully, PATCH updates partially, DELETE removes, while HEAD and OPTIONS are quiet helpers for checking metadata and permissions.
• Safe means “only reads, changes nothing.” Idempotent means “repeating it gives the same end result.”
• GET, HEAD, and OPTIONS are safe; GET, HEAD, OPTIONS, PUT, and DELETE are idempotent; POST is neither.
• Picking the correct method keeps browsers, crawlers, and other systems from causing accidental harm — and makes your intentions obvious to anyone reading along.