HTTP methods and idempotency

HTTP methods, idempotency, PUT vs PATCH

The main methods: GET retrieves a resource, POST creates, PUT replaces completely, PATCH changes partially, DELETE removes. HEAD also returns only headers, and OPTIONS returns the allowed methods, which CORS preflight uses. Safe methods don't change the server state: GET, HEAD, OPTIONS.

An idempotent method is one where several identical requests give the same server state as one. GET, PUT and DELETE are idempotent, POST isn't: two POSTs create two records. The response may differ, for example a repeated DELETE returns 404 instead of 204.

PUT sends the full representation of a resource, and fields absent from the body may be reset. PATCH sends only the fields that change. PATCH isn't guaranteed to be idempotent, for example the operation "increase the counter by 1". This is worth checking in tests: a repeated PUT must not create duplicates.

The methods table

An idempotent method is one where a repeated identical request doesn't change the server state beyond the first. A safe one is one that doesn't change data at all.

Method	What for	Body	Idempotent	Typical success code
GET	Retrieve a resource or a list	No	Yes (and safe)	200
POST	Create a resource or perform an action	Yes	No	201
PUT	Replace a resource completely	Yes	Yes	200 or 204
PATCH	Change individual fields	Yes	Not guaranteed	200
DELETE	Remove a resource	Usually no	Yes	204 or 200
HEAD	Like GET but only headers	No	Yes	200
OPTIONS	Which methods are allowed; CORS preflight	No	Yes	204

Idempotency concerns the server state, not the response. A repeated DELETE may return 404 instead of 204, but the resource is deleted all the same, so the method remains idempotent. HEAD is useful when you need to check that a resource exists or a file's size without downloading the body.

In an interview: GET, PUT, DELETE, HEAD and OPTIONS are idempotent, POST isn't, and PATCH is not guaranteed. Safe methods, like GET and HEAD, don't change data at all.

PUT vs PATCH and Idempotency-Key in fintech

PUT vs PATCH. PUT sends the whole object, and a field you didn't pass may become empty. PATCH changes only the passed fields. This is a ready test case: do a PUT without one field and check through GET what happened to it. If the field was wiped and the documentation says PUT is a full replacement, the behaviour is correct; if the API behaves like PATCH, it is a deviation from the contract.

Fintech. POST is non-idempotent, so pressing "Pay" again or repeating a request after a network timeout may debit money twice. The protection is the Idempotency-Key header: the client generates a unique key, the server remembers it and on a repeat returns the same result without creating a second payment.

How I test it:

Send POST /transfers with the key K1, get 201 and the transfer id.
Send the same request with the same K1.
Check that the response contains the same id, and that in the database or history there is one transaction.
Send a different body with the same K1 and check that the server returns an error (often 409 or 422), not quietly executing a new payment.

In an interview: PUT replaces a resource entirely, PATCH changes only the passed fields, and I check this with a GET after a PUT without one field. For payments POST is protected by Idempotency-Key, and I test that a repeat with the same key doesn't create a second transaction.