Methods Tell the Server Your Intent
HTTP methods aren't just conventions, they carry semantic meaning that middleware, caches, and proxies rely on. Mark a method as safe, and CDNs know they can cache the response. Mark it as idempotent, and retry logic knows it's safe to resend the request after a network timeout. Understanding REST API HTTP methods this way, as contracts rather than labels, is what separates APIs that behave predictably from ones that surprise you in production.
GET - safe and idempotent. Calling it 100 times has the same effect as calling it once. Caches can store the response.
POST - creates something new. Not idempotent. Calling it twice might create two resources.
PUT - replaces the entire resource. Idempotent. Calling it twice gives the same result as calling it once.
PATCH - a partial update. Apply changes to specific fields without sending the whole resource.
DELETE - removes the resource. Idempotent. Deleting something twice shouldn't error (the resource is already gone).
HEAD - like GET but returns only headers, no body. Useful for checking if a resource exists or getting its size.
OPTIONS - asks what methods are available for a resource. Used by browsers for CORS preflight requests.
Idempotency: Why It Matters
Picture a real scenario: you click "Submit Payment" and the browser hangs. Did the payment go through? Is your account charged? If you click again, will you be double-charged?
Architecture overview
If the payment endpoint is idempotent (the same request always produces the same result), the retry is safe. If it isn't, you might pay twice. That's why POST endpoints in production APIs need an idempotency key, a unique ID the client sends so the server can detect and ignore duplicates:
Status Codes: The Full Picture
HTTP status codes are grouped by their first digit:
The Status Codes You Will Actually Use
Out of roughly 70 defined status codes, you'll use about a dozen in practice. Here are the HTTP status codes explained in terms of when to reach for each one:
200 OK - generic success for GET, PUT, PATCH, DELETE
201 Created - success for a POST that created a resource. Include a Location header pointing to the new resource.
204 No Content - success but no response body (common for DELETE)
400 Bad Request - malformed request, validation errors
401 Unauthorized - not authenticated (no token or an invalid one)
403 Forbidden - authenticated but not authorized to access this resource
404 Not Found - the resource doesn't exist
409 Conflict - request conflicts with current state (duplicate email, version conflict)
422 Unprocessable Entity - valid syntax but semantically wrong (age can't be negative)
429 Too Many Requests - rate limited. Include a Retry-After header.
500 Internal Server Error - an unexpected bug. Never return this intentionally.
502 Bad Gateway - your server is fine but an upstream service failed
503 Service Unavailable - your server is overloaded or in maintenance. Include Retry-After.
Decision Tree: Which Status Code?
Common Mistakes
Returning 200 with an error message in the body. This breaks every HTTP client's error handling and makes monitoring useless, since all requests look "successful."
Using GET with a request body. It's technically allowed but universally misunderstood. Use query parameters or POST instead.
Returning 500 for every error. Clients can't distinguish their mistakes from yours, and they have no way to know if retrying will help.
Using 404 for an "empty list." An empty list is a valid response (200 with []). 404 means the endpoint itself doesn't exist.
Returning 200 OK for partial failures in batch operations. Use 207 Multi-Status instead.
Headers That Professional APIs Include
The Cache-Control header above ties directly into how caches and CDNs decide what to store and for how long, a topic worth understanding in more depth in Caching Strategies: Invalidation, Placement, and Real-World Trade-offs. And if you're designing a system where multiple services sit behind a single API surface, see how method and status code conventions carry through gateways in API Gateway, BFF, tRPC, and the Multi-Protocol Architecture.
Interview Tip
When designing an API in an interview, write out the status codes for each endpoint explicitly. For a POST endpoint, say: "201 for success, 400 for validation errors, 401 for missing auth, 409 for duplicate resources, 429 for rate limiting." This shows you're thinking about error paths, not just the happy path. Interviewers love seeing PUT marked as idempotent and POST paired with an idempotency key.
These conventions are also foundational to broader low-level design interviews, where you're expected to reason about resource modeling and API contracts alongside class design. If you want a refresher on that, LLD: Master the Building Blocks of Low-Level Design is a good companion piece.
Key Takeaway
HTTP methods explained simply: they express intent. Status codes communicate outcomes. Use them correctly and your API becomes self-documenting. Idempotency guarantees make retry logic safe. Never wrap errors in 200 responses, it breaks every tool in the HTTP ecosystem.