🧰 Core Tech Refresher

REST API Design

Statelessness, status codes, idempotent verbs, versioning.

Statelessness — each request carries everything needed to process it; no server-side session state between requests (this is also why REST APIs scale horizontally so easily — any instance can handle any request).

Idempotency by verb — GET, PUT, DELETE are idempotent (same call N times = same end state); POST is not. This matters directly for the messaging section: an at-least-once message delivery guarantee needs the handler to be idempotent even if the transport retries, which is exactly the same concept applied to consumers instead of HTTP verbs.

Status codes that actually get checked in interviews: 200 vs 201 (created, usually with a Location header) vs 204 (no content, e.g. successful DELETE) vs 400 (bad request/validation) vs 409 (conflict, e.g. optimistic concurrency violation) vs 422 (semantically invalid) vs 500.

Versioning — URL segment (/v1/orders), header, or query string. URL segment is the most discoverable/cacheable; header-based keeps URLs clean but is less visible. Know the tradeoff exists, don't just pick one blindly.

Flashcards (3)

Why does REST statelessness matter for scalability?

tap to reveal answer

No server-side session state means any request can be handled by any instance behind a load balancer — you can scale horizontally without sticky sessions or shared session stores.

Which common HTTP verbs are idempotent, and why does that matter for message-based systems too?

tap to reveal answer

GET, PUT, DELETE (and HEAD) are idempotent — repeating them produces the same end state. It matters for messaging because at-least-once delivery means handlers can receive the same message twice, so they need the same idempotency property.

What HTTP status code fits an optimistic-concurrency conflict on update, and what's the difference from a plain 400?

tap to reveal answer

409 Conflict — the request is well-formed but conflicts with current server state (e.g. stale ETag/RowVersion). 400 is for malformed/invalid input, a different failure category.