All 15 HTTP & Web Servers questions
More in HTTP & Web Servers
How would you create a basic HTTP server in Node.js using only the built-in node:http module, without any framework? What is the difference between an HTTP request header and a query parameter, and when should each be used to pass information to a Node.js server? What is the difference between HTTP/1.1 and HTTP/2, and how does Node.js support HTTP/2 via the node:http2 module? What is HTTP keep-alive, and how does it improve performance for a Node.js server handling many requests from the same client? What is content negotiation in HTTP, and how would a Node.js API implement it to return either JSON or XML based on a client's Accept header? What is the purpose of the HTTP OPTIONS method, and how does it relate to CORS preflight requests? What is the difference between a 301 and a 302 HTTP redirect, and when should a Node.js application use each? What is the purpose of the Content-Length and Transfer-Encoding: chunked headers, and why can't a response use both simultaneously? How would you implement Server-Sent Events (SSE) in Node.js to push real-time updates to a browser client over a single long-lived HTTP connection? How would you implement HTTP/2 server push in Node.js, and why has server push become less commonly recommended over time?
Advertisement
Back to results for “Error Handling”
Node.js › HTTP & Web Servers

What is the difference between HTTP methods GET, POST, PUT, PATCH, and DELETE, and what does 'idempotent' mean in this context?

Intermediate

Answer

GET retrieves a resource without side effects; POST creates a new resource or triggers a non-idempotent action; PUT replaces a resource entirely with the provided representation; PATCH applies a partial update to a resource; DELETE removes a resource. An operation is idempotent if performing it multiple times has the same effect as performing it once -- GET, PUT, and DELETE are conventionally idempotent (repeating a DELETE on an already-deleted resource typically still results in it being gone), while POST is conventionally not (submitting the same POST twice, like a payment, could create two separate resources).
app.get('/users/:id', getUserHandler);       // idempotent, no side effects
app.put('/users/:id', replaceUserHandler);   // idempotent, full replacement
app.patch('/users/:id', updateUserHandler);  // partial update
app.post('/users', createUserHandler);       // NOT idempotent, creates a new resource each time
app.delete('/users/:id', deleteUserHandler); // idempotent
Real-world example A payment API deliberately implements its charge-creation endpoint as POST (correctly non-idempotent by default) but requires an explicit idempotency key parameter specifically to make repeated identical requests safe, since a naive retry of a plain POST could otherwise result in a customer being charged multiple times.

Common follow-ups: Why does the idempotency convention for these HTTP methods matter for how proxies and clients handle automatic retries?;How does the earlier-discussed idempotency key pattern for payments relate to this HTTP-method-level idempotency convention?

RESTful API Design with Express;Error Handling
All 15 HTTP & Web Servers questions