REST APIs should handle errors in which of the following ways to be developer-friendly?

• A. Return HTML error pages for all errors.
• B. Always use HTTP 200 and include error data in body.
• C. Use consistent error payloads with HTTP status codes, include error codes, messages, and actionable details.
• D. Expose internal stack traces in production responses.

Answer: (C)

In REST APIs, errors should be communicated through standard HTTP status codes plus a consistent, machine-readable error payload. Using the appropriate HTTP status (like 400 for bad requests, 404 for missing resources, 401/403 for authentication/authorization issues, 500 for server errors) immediately signals the kind of problem to the client. Pairing that with a structured error object that includes an error code, a clear message, and actionable details lets developers programmatically handle failures, display helpful user messages, and guide remediation steps. This consistency also avoids exposing internal implementation details while still giving enough context to fix the issue quickly.

For example, a failed request might return a 404 with a body that looks like:

{

"error": {

"code": "resource_not_found",

"message": "User not found",

"details": { "id": "123" }

}

}

Why the other approaches fall short: returning HTML error pages is not machine-friendly for API clients; always returning 200 hides real errors and forces clients to parse the body to detect failures; exposing internal stack traces in production poses security risks and confuses users with low-level details. The best practice is clear, standard status codes complemented by a consistent, actionable error payload.