How should a REST API format error responses?
Assesses fundamental understanding of REST API Design conventions, runtime behavior, and memory/performance considerations.
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
Use one consistent, machine-readable shape. A widely adopted choice is RFC 7807 application/problem+json:
{
"type": "https://example.com/problems/insufficient-funds",
"title": "Insufficient funds",
"status": 422,
"detail": "Account balance is 10 USD, required 50 USD.",
"instance": "/payments/abc",
"errors": [
{ "field": "amount", "code": "above_balance" }
]
}
Key properties: a stable type or code clients can branch on, a human-readable message, the HTTP status mirrored in the body, and field-level details for validation errors. Never leak stack traces, SQL or internal hostnames. Include a correlation or request id so support can trace the failure in logs.
Design the error contract once and reuse it across every endpoint; inconsistent error shapes are one of the most common sources of brittle client code.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.