Blog
3 min read

GET vs POST (and PUT, PATCH, DELETE): HTTP Methods Explained

Every request to a web server has a method that says what it wants to do. GET reads, POST creates, PUT and PATCH update, DELETE removes. The differences that matter in practice — caching, safety, idempotency, where the data goes — and the mistakes AI-generated APIs make.

Every request your browser or app sends to a server includes a method — a verb that says what it wants to do. You'll see these in browser dev tools, API docs and AI-generated code:

Method Means Example
GET Read something Load a list of posts
POST Create something / do an action Sign up, place an order
PUT Replace something entirely Save a whole settings object
PATCH Change part of something Rename a project
DELETE Remove something Delete a comment

These map neatly onto the four CRUD operations.

GET vs POST: the differences that matter

Where the data goes. GET puts parameters in the URL: /search?q=shoes&page=2. POST puts data in the request body, which isn't part of the URL.

What gets logged and shared. URLs end up in browser history, server logs, analytics, and the address bar for anyone looking over your shoulder. Never send passwords, tokens or personal data in a GET URL. Use POST with a body.

Caching. Browsers and CDNs may cache GET responses. POST responses aren't cached by default. (HTTP caching headers)

Safety. GET should never change anything. Browsers prefetch links, crawlers follow them, and link previews in chat apps open them. If GET /delete-account?id=5 deletes an account, a Slack link preview could delete someone's account. Anything that changes data must be POST, PUT, PATCH or DELETE.

Bookmarking and sharing. A GET URL can be bookmarked and shared. That's why search results and filters should use GET.

Refreshing. Refresh a page loaded via POST and the browser asks "Resubmit the form?" — because doing it twice might order twice. The usual fix is to redirect to a GET page after a successful POST.

PUT vs PATCH

  • PUT replaces the whole resource. Send { "name": "New" } with PUT and, strictly, other fields are wiped.
  • PATCH changes only the fields you send.

In practice many APIs use PATCH for edits and rarely use PUT. Pick one convention and stick to it. (REST API design)

Idempotency: what happens if it runs twice?

Networks fail, and clients retry. So it matters whether repeating a request is harmless:

Method Safe (no changes)? Idempotent (same result if repeated)?
GET Yes Yes
PUT No Yes — replacing with the same thing twice is the same
DELETE No Yes — deleting twice leaves it deleted
PATCH No Not necessarily
POST No No — two POSTs can create two orders

That's why payment APIs use idempotency keys for POST requests. (Idempotency keys explained)

HTML forms only do GET and POST

A plain <form> can only send GET or POST. For PUT, PATCH and DELETE you use JavaScript's fetch:

await fetch(`/api/posts/${id}`, {
  method: 'PATCH',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ title: 'New title' }),
})

Mistakes AI-generated APIs make

  • Changing data on GET — GET /api/like?postId=5. Make it POST.
  • Sensitive data in query strings — ?token=... or ?email=... in URLs that get logged.
  • Everything is POST — works, but you lose caching for reads and clarity for everyone else.
  • No authorisation check on DELETE/PATCH — the method is right, but anyone can delete anyone's data. (IDOR explained)

The summary

  • GET reads, POST creates/acts, PUT replaces, PATCH updates part, DELETE removes.
  • GET data goes in the URL (logged, cached, shareable); POST data goes in the body.
  • Never change data on GET; never put secrets in URLs.
  • POST isn't idempotent — use idempotency keys where duplicates would hurt.

EasySpawn runs your API and frontend on one server with HTTPS, so Claude Code can build endpoints, call them, and check the results in the same place. See how it works or join the waitlist.

Related: What Is an API? · HTTP Status Codes Explained · Designing a REST API · What Is CRUD?

Keep reading