HTTP status codes used consistently

Returning 200 for every response — including errors — forces consumers to parse the body to determine success, destroys the value of HTTP-level monitoring (uptime checks, load balancer health probes, APM error rate dashboards all become blind), and breaks any tooling that relies on status codes for routing decisions. Returning 500 for validation failures (which are client errors, not server errors) skews error rate metrics and triggers false alerts. iso-25010:2011 compatibility.interoperability requires semantically correct status codes because the entire HTTP ecosystem — proxies, CDNs, clients — makes decisions based on them.

Use HTTP status codes to convey the outcome — not just a 200 with an error flag in the body:

// Standard status code mapping:
// GET    /api/users     -> 200
// GET    /api/users/:id -> 200 (found) or 404 (not found)
// POST   /api/users     -> 201 (created)
// PUT    /api/users/:id -> 200 (updated) or 404 (not found)
// DELETE /api/users/:id -> 204 (deleted) or 404 (not found)

// Client errors (4xx):
// 400 -> validation error, malformed request
// 401 -> not authenticated
// 403 -> authenticated but not permitted
// 404 -> resource not found
// 409 -> conflict (duplicate, concurrent edit)
// 422 -> valid JSON but semantic error

// Server errors (5xx):
// 500 -> unhandled exception, not validation failure

See the error-schema check for structuring error response bodies consistently alongside these status codes.