HTTP methods and requests

The method is the verb of an HTTP request: it tells the server what to do with the resource in the URL. "What is the difference between PUT and PATCH?" and "Which methods are idempotent?" are among the most asked API questions, because the answers show whether you understand what a request does to the data. The answers come from the HTTP standard, RFC 9110 (an RFC is a public document that defines an internet standard; PATCH is defined separately, in RFC 5789). The status codes named below, such as 200 or 404, are explained in the status codes topic.

The main methods

GET asks for the current state of a resource: GET /users/42. It must not change anything. A body sent with GET has no defined meaning, and some servers and proxies (programs that pass requests on between the client and the server) reject it, so filters belong in the query string. Typical answers are 200 OK with the data, or 404 Not Found.

POST sends data for the server to process. Most often it creates a new item in a collection: POST /users with a JSON body. A good create returns 201 Created, usually with a Location header pointing at the new user. Sending the same POST twice normally creates two users.

PUT replaces the resource at a known URL with the body you send: PUT /users/42. Think "make it look exactly like this". Fields you leave out may be cleared. RFC 9110 says a PUT that creates a resource must answer 201, and one that replaces an existing resource answers 200 or 204.

PATCH applies a partial change: PATCH /users/42 with only {"email": "new@example.com"}. The other fields stay as they were.

DELETE removes the resource. Typical answers are 204 No Content, 200 OK with a status body, or 202 Accepted if the deletion happens later. A GET afterwards should return 404.

HEAD is GET without the body: the same status and headers, no content. It checks that a big file exists without downloading it. OPTIONS asks what a resource supports; browsers also send it automatically as a CORS preflight: a check that asks a server whether a web page from another website is allowed to call it.

Safe and idempotent

A method is safe if the client asks for no change on the server: GET, HEAD, OPTIONS (and TRACE, a rarely used method that echoes the request back). Caches (which store answers for reuse), search crawlers and browsers rely on this. If a GET endpoint changes data, for example GET /orders/5/cancel, report it as a bug: a program that only opens the link, such as a chat app showing a preview, could cancel an order.

A method is idempotent if sending the same request many times leaves the server in the same state as sending it once. Per RFC 9110 that is PUT, DELETE and all safe methods. Example: PUT /users/42 with the same body ten times leaves user 42 exactly as one call does. POST is not idempotent. PATCH is not guaranteed to be: "set the email to x" is harmless to repeat, but "add 1 to the quantity" is not.

Idempotency is about the server state, not the response. A second DELETE may return 404 instead of 204, and the method is still idempotent, because nothing more was removed. It matters because networks fail: if the connection drops before the response arrives, the client cannot tell whether the server acted. Repeating an idempotent request is harmless, while repeating a POST may create a second order or charge a card twice. That is why payment APIs often accept an idempotency key, a unique value in a header that lets the server answer a repeat with the original result.

What to test for each method

• GET: the right data and fields; 404 for unknown ids; filters, sorting and paging; nothing changed after the call.
• POST: 201 and the returned fields; the record really exists (read it back); validation errors for missing or invalid fields; duplicates; nothing saved when the request is rejected.
• PUT: the stored resource now equals the body; omitted fields behave as documented; repeating the same PUT changes nothing more.
• PATCH: only the sent fields change, so read back and compare the others; invalid values are rejected.
• DELETE: the resource is gone; repeating it gives the documented answer; nothing else is deleted; you cannot delete what you do not own.
• Unsupported methods: expect 405 Method Not Allowed with an Allow header listing the supported ones, not a 500 or a silent 200.

A short worked example

Suppose user 42 is {"name": "Asha", "email": "a@example.com", "city": "Pune"}.

PATCH /users/42   {"email": "asha@example.com"}
GET   /users/42 -> {"name": "Asha", "email": "asha@example.com", "city": "Pune"}

PUT   /users/42   {"name": "Asha", "email": "asha@example.com"}
GET   /users/42 -> city is now missing or null, if the API follows PUT strictly

The read-back is the habit interviewers look for: a status code alone does not prove what happened to the data.

How to answer in an interview

Give one line per method with an example URL and its typical status code, then define safe and idempotent in one sentence each. Finish with why it matters: "Clients retry after timeouts, so a retried POST can create a duplicate order; an idempotency key prevents that." If asked "PUT or PATCH?", answer with the email example above.

Common mistakes

• Saying "PUT updates, POST creates" and stopping there: PUT replaces the whole resource and can clear fields.
• Calling DELETE not idempotent because the second call returns 404.
• Claiming POST is more secure than GET; only HTTPS encrypts anything.
• Checking only the status code instead of reading the data back.

Recap

GET reads, POST creates or processes, PUT replaces, PATCH changes part, DELETE removes. Safe methods only read; idempotent methods can be repeated without extra effect, which makes retries safe. Test each method by checking the stored data, not only the response. The next topic explains what each status code promises.