HTTP Methods Explained for New Web Developers

Posted November 29, 2025 by Karol Polakowski

Understanding HTTP methods is essential for building reliable, predictable web APIs. This article breaks down the most common methods (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS), explains concepts like idempotency and safety, and shows practical examples (Express routes, curl, fetch) you can reuse in your projects.

HTTP methods — the big picture

HTTP methods (sometimes called verbs) communicate intent: you ask the server to retrieve, create, update, or remove resources. Two cross-cutting properties matter:

  • Safe: a method that does not modify server state (e.g., GET, HEAD). Safe methods are read-only from the client’s perspective.
  • Idempotent: repeating the same request has the same effect as doing it once (e.g., GET, PUT, DELETE are idempotent; POST usually is not).

Cacheability also varies: GET responses are cacheable (when headers permit); POST responses typically aren’t.

Common methods (what they mean and when to use them)

GET

  • Purpose: Retrieve a representation of a resource.
  • Safe: Yes. Idempotent: Yes. Cacheable: Yes (when headers allow).
  • Body: Typically no request body. Use query parameters or path.
  • Typical status codes: 200, 304, 404.

Example fetch from the browser:

// javascript
fetch('/api/users/123')
  .then(r => r.json())
  .then(user => console.log(user));

POST

  • Purpose: Create a new resource or submit data to be processed.
  • Safe: No. Idempotent: No (multiple identical POSTs often create duplicates).
  • Cacheable: Generally not.
  • Typical status codes: 201 (created), 202 (accepted), 400 (bad request).

PUT

  • Purpose: Replace a resource entirely at a known URL.
  • Safe: No. Idempotent: Yes (replacing with the same payload is repeatable).
  • Use when you can provide a complete representation.
  • Typical status codes: 200, 204, 201 (if created).

PATCH

  • Purpose: Apply partial modifications to a resource.
  • Safe: No. Idempotent: Not guaranteed, but often designed to be idempotent.
  • Use for partial updates (e.g., change only email field).
  • Typical status codes: 200, 204.

DELETE

  • Purpose: Remove a resource.
  • Safe: No. Idempotent: Yes (deleting an already-deleted resource should be a no-op or 404).
  • Typical status codes: 200, 202, 204, 404.

HEAD

  • Purpose: Same as GET but without a response body — useful for checking headers, caching, or existence.
  • Safe: Yes. Idempotent: Yes.
  • Typical status codes: mirrors GET.

OPTIONS

  • Purpose: Discover the communication options for a resource (CORS preflight uses OPTIONS).
  • Safe: Yes. Idempotent: Yes.
  • Use to return Allow header or CORS headers.

Practical examples (Express + curl)

Express routes for common methods:

// javascript
const express = require('express');
const app = express();
app.use(express.json());

app.get('/items/:id', (req, res) => res.json({ id: req.params.id }));
app.post('/items', (req, res) => res.status(201).json({ id: 42, ...req.body }));
app.put('/items/:id', (req, res) => res.json({ id: req.params.id, ...req.body }));
app.patch('/items/:id', (req, res) => res.json({ id: req.params.id, ...req.body }));
app.delete('/items/:id', (req, res) => res.status(204).send());

app.options('/items', (req, res) => res.set('Allow', 'GET,POST,OPTIONS').send());

app.listen(3000);

Curl examples for POST and PUT:

# bash
curl -X POST -H "Content-Type: application/json" \
  -d '{"name":"Alice"}' http://localhost:3000/items

curl -X PUT -H "Content-Type: application/json" \
  -d '{"name":"Alice Updated"}' http://localhost:3000/items/42

Idempotency, safety, and why they matter

  • Idempotency helps clients safely retry requests (important for network failures and distributed systems).
  • Safety tells caches and tools that the method should not cause side effects.
  • Design APIs to make idempotency clear: prefer PUT for full replacement, PATCH for partial updates, and POST for actions/creation that shouldn’t be retried blindly.

Best practices

  • Use nouns (resources) in URLs, not verbs: /orders, /users/123.
  • Return appropriate status codes: 201 for created, 204 for successful operations with no body, 400 for validation errors.
  • Validate Content-Type and parse only supported content types (e.g., application/json).
  • Avoid relying on request bodies for GET; some proxies ignore or strip them.
  • Use OPTIONS to handle CORS preflight; keep server responses minimal and correct (Allow, Access-Control-Allow-* headers).
  • For long-running tasks, return 202 Accepted with a Location header to a status resource.

Troubleshooting common issues

  • CORS failing preflight: ensure OPTIONS handler returns Access-Control-Allow-Methods and Access-Control-Allow-Origin.
  • HTML forms: browsers only support GET and POST. Use method-override middleware or use POST with a hidden _method field.
  • Proxies or firewalls blocking methods: fallback patterns use POST with an action field, but document the behavior carefully.
  • Unexpected 415 Unsupported Media Type: check Content-Type header.

Quick reference cheat-sheet

  • GET: read, cacheable, safe, idempotent.
  • POST: create/process, not idempotent.
  • PUT: replace a resource, idempotent.
  • PATCH: partial update, not guaranteed idempotent (design it that way if needed).
  • DELETE: remove, idempotent.
  • HEAD: get headers only.
  • OPTIONS: discover allowed methods / handle CORS.

HTTP methods give you a shared language between client and server. Use them consistently, pick clear status codes, and design endpoints around resource semantics — this results in APIs that are easier to maintain, cache, and scale.