← Dashboard

cheat sheets / back end

Back-End Cheat Sheets — HTTP Status Codes, SQL & Express

Five references for the lookups back-end work rotates through, plus the status-code decisions that actually matter: 401 against 403, 404 against 410, and why idempotency changes what a client can safely retry.

updated aug 2026·5 references·a 7-minute read·free

Back-end work is a rotation of the same lookups. Which status code fits this response, how do I write that join, what is the regex for this, which Express method do I need. The five references below cover the recall part. The sections after them cover the decisions a reference cannot make for you, mostly around HTTP semantics, where the difference between two similar-looking codes changes how every client behaves.

01 · FRAMEWORKS & DATA

Servers & databases

The frameworks and query languages behind most back ends.

02 · MID-DEBUG LOOKUPS

HTTP status & regex

The two references you will open in the middle of fixing something.

03 · STATUS CODES

The distinctions that change client behavior

Status codes are a contract, not decoration. Clients, caches, proxies, and crawlers all make decisions based on them, so choosing carelessly produces bugs in software you do not control. The classes are straightforward: 2xx succeeded, 3xx means look elsewhere, 4xx blames the request, 5xx blames the server. Within that, a few pairs get confused constantly.

401 against 403

401 means the request was not authenticated, so credentials are missing or invalid and retrying with valid ones may work. 403 means the server knows who you are and you still may not do this, so retrying with the same identity will not help. Returning 401 for an authorization failure sends clients into pointless re-authentication loops.

404 against 410

404 means not found, with no claim about whether it ever existed or might come back. 410 states the resource is deliberately gone. For search engines this matters: a 410 is a stronger, faster removal signal than a 404, which is worth using when you intentionally retire a URL.

400 against 422

400 fits a request the server cannot parse or that is structurally wrong. When the syntax is fine but the content fails validation, a more specific code communicates more, though consistency across your API matters more than the precise choice. Whichever you pick, return the same one for the same class of problem everywhere.

WATCH OUTNever return 200 for an error. An error payload wrapped in a success status defeats every layer that reads status codes: client libraries treat it as success, monitoring records no failure, and retries never trigger. If it failed, say so in the status line.

04 · API DESIGN

Idempotency, middleware order, and errors

An operation is idempotent when performing it repeatedly has the same effect as performing it once. GET, PUT, and DELETE are expected to be idempotent; POST is not. This is not academic: it determines what a client, proxy, or retry layer may safely repeat after a timeout. When a request times out, the client has no idea whether the server processed it, and only idempotency makes retrying safe. Designing operations to be idempotent where possible removes an entire category of duplicate-record bugs.

In Express, middleware runs in the order it is registered, and that ordering is the source of most surprises. Body parsing has to come before anything that reads the body, authentication before the routes it protects, and error handlers last. A middleware that neither sends a response nor passes control onward leaves the request hanging until it times out, with no error to explain why.

Error handling deserves deliberate attention rather than being left to defaults. Returning a stack trace to a client leaks internal structure that is useful to an attacker and useless to a legitimate consumer. Log the detail server-side, return something actionable and generic, and make sure asynchronous failures reach the error handler rather than vanishing.

WORTH KNOWING401 vs 403404 vs 410idempotencymiddleware ordernever 200 on error

05 · FAQ

Frequently asked questions

Are these back-end cheat sheets free?

Yes. All five are free to read with no account. The HTTP status reference is MDN's, maintained by Mozilla, and the others are free pages on QuickRef and Devhints.

What is the difference between 401 and 403?

401 means the request was not authenticated, so credentials are missing or invalid and retrying with valid ones may succeed. 403 means the server knows who you are and the action is still not permitted, so retrying with the same identity will not help.

When should I return 410 instead of 404?

Use 410 when a resource is deliberately and permanently gone. It is a stronger and faster removal signal for search engines than 404, which makes no claim about whether the resource ever existed or might return.

What does idempotent mean for an API?

An operation is idempotent when repeating it has the same effect as doing it once. GET, PUT, and DELETE are expected to behave this way and POST is not, which determines what a client can safely retry after a timeout when it cannot tell whether the server processed the original request.

Why does my Express route never respond?

Usually because a middleware neither sent a response nor passed control to the next handler, leaving the request hanging until it times out. Middleware order matters too: body parsing must come before anything reading the body, and error handlers must be registered last.

More cheat sheets

Quick references by area.