HTTP Methods Explained: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS

HTTP methods are the verbs of an API: they tell the server what you want to do with a resource. Mix them up and you get bugs like a “GET” that deletes data or a retry that charges a customer twice. In this lesson you will learn all seven methods testers use, the difference between PUT and PATCH, what “safe” and “idempotent” really mean, and you will run each method on a live object you create yourself.

Real-Life Example: Managing Your Address Book in a Shopping App

This mapping of methods to actions is called CRUD: Create (POST), Read (GET), Update (PUT/PATCH) and Delete (DELETE).

All HTTP Methods at a Glance

Two rarer methods: TRACE (echoes the request, should be disabled in production for security) and CONNECT (used by proxies for HTTPS tunnels).

GET: Read Data

GET retrieves data and must never change anything on the server. Parameters go in the URL path or query string.

curl -i \
  "https://sqatools.in/wp-json/sqa-api/v1/users?role=admin&sort=age&order=desc"

Test ideas: correct data and count; filters and sorting; 404 for a missing id; 400 for an invalid id (/users/abc); calling it twice changes nothing; sensitive data not exposed; response time.

POST: Create a New Resource

POST sends data in the body; the server decides the new id. A correct create returns 201 Created and a Location header.

curl -i \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"name":"Office address","data":{"city":"Pune","pin":"411001"},"ttl":300}' \
  "https://sqatools.in/wp-json/sqa-api/v1/objects"

Test ideas: 201 + Location; body echoes what you sent; required fields missing → 422; extra unknown fields; client trying to set the id (the practice API rejects it with 422); duplicate submission.

PUT: Replace (or Create at a Known URL)

PUT sends the complete new version of a resource to its URL. Any field you leave out is removed or reset. If the resource does not exist, many APIs create it (called an upsert).

On the practice API you choose the id. The first PUT returns 201 Created; repeating the same PUT returns 200 OK with the same content, which is what idempotent means.

curl -i \
  -X PUT \
  -H "Content-Type: application/json" \
  -d '{"name":"Home address","data":{"city":"Mumbai","pin":"400001"},"ttl":300}' \
  "https://sqatools.in/wp-json/sqa-api/v1/objects/my-address-01"

Test ideas: full replacement (omitted fields disappear); name missing → 422 (PUT needs the full representation); id in body different from id in URL → 422; repeat the call → same state; version increments.

PATCH: Update Only Some Fields

PATCH sends only the fields that change. The practice API uses JSON Merge Patch rules: fields you send are merged in, and a field set to null is removed.

curl -i -X PATCH "https://sqatools.in/wp-json/sqa-api/v1/objects/my-address-01" \
  -H "Content-Type: application/json" \
  -d '{"data":{"pin":"400002"}}'

Result: city stays “Mumbai”, pin becomes “400002”, version goes up by 1, and the ETag changes from "v1" to "v2".

Test ideas: only sent fields change; null removes a key; empty body {} → 422 “nothing to update”; PATCH on a missing id → 404; read-only fields (id, created_at) cannot be patched.

PUT vs PATCH: The Most Asked Interview Question

Example: the stored object is {"name":"Home","data":{"city":"Mumbai","pin":"400001"}}.

• PUT {"name":"Home","data":{"pin":"400002"}} → city is gone.
• PATCH {"data":{"pin":"400002"}} → city is kept.

DELETE: Remove a Resource

DELETE removes the resource. The common success code is 204 No Content (empty body).

curl -i \
  -X DELETE \
  "https://sqatools.in/wp-json/sqa-api/v1/objects/my-address-01"

Press Send twice. The first call returns 204, the second 404. Is that still idempotent? Yes: idempotency is about the server state (the object is gone either way), not about the status code.

Test ideas: 204 then GET returns 404; deleting twice; deleting without permission → 403; deleting a resource that has children (an order with payments); soft delete vs hard delete; DELETE on read-only resources → 405 (try DELETE /products/101).

HEAD and OPTIONS: The Methods Testers Forget

HEAD

Returns exactly the headers a GET would return, but no body. Used to check if a resource exists, its size (Content-Length) or its version (ETag) without downloading it, for example before downloading a 2 GB file.

curl -I \
  "https://sqatools.in/wp-json/sqa-api/v1/users/1"

OPTIONS

Asks which methods are allowed. The answer comes in the Allow header. Browsers also send OPTIONS automatically as a CORS pre-flight before cross-origin PUT/DELETE requests.

curl -i \
  -X OPTIONS \
  "https://sqatools.in/wp-json/sqa-api/v1/users"

405 Method Not Allowed

When you use a method an endpoint does not support, the correct answer is 405 with an Allow header listing valid methods. On the practice API, POST /users returns: “This endpoint supports GET, HEAD only.” A 404 or 500 here would be a bug.

Safe vs Idempotent, Explained Simply

• Safe = read-only. Calling it does not change data. (GET, HEAD, OPTIONS)
• Idempotent = calling it once or 10 times leaves the server in the same state. (All safe methods + PUT + DELETE)

Why testers care: networks fail, and clients and gateways retry. Retrying idempotent requests is safe; retrying POST without an idempotency key can create duplicates.

All Methods in One Playwright Test

import { test, expect } from '@playwright/test';

const BASE = 'https://sqatools.in/wp-json/sqa-api/v1';

test('HTTP methods on one object', async ({ request }) => {
  const id = `pw-${Date.now()}`;
  const url = `${BASE}/objects/${id}`;

  // PUT creates (201), PUT again is idempotent (200, same data)
  const body = { name: 'Home', data: { city: 'Mumbai', pin: '400001' }, ttl: 120 };
  expect((await request.put(url, { data: body })).status()).toBe(201);
  expect((await request.put(url, { data: body })).status()).toBe(200);

  // PATCH changes one field and keeps the rest
  const patched = await (await request.patch(url, { data: { data: { pin: '400002' } } })).json();
  expect(patched.data).toEqual({ city: 'Mumbai', pin: '400002' });

  // HEAD: headers only, no body
  const head = await request.head(url);
  expect(head.status()).toBe(200);
  expect((await head.body()).length).toBe(0);

  // DELETE twice: 204 then 404 (state is the same: gone)
  expect((await request.delete(url)).status()).toBe(204);
  expect((await request.delete(url)).status()).toBe(404);
});

test('unsupported method returns 405 with Allow header', async ({ request }) => {
  const res = await request.post(`${BASE}/users`, { data: {} });
  expect(res.status()).toBe(405);
  expect(res.headers()['allow']).toBeTruthy();
});

Interview Questions: HTTP Methods