Backend
RFC 9457: A Simple Standard for HTTP API Errors
API errors are often designed from scratch: message, error, code, reason, nested objects, and countless local conventions.
RFC 9457 provides a simple common format: Problem Details for HTTP APIs.
Instead of a custom response like:
{
"error": "user_not_found",
"message": "User not found"
}
you can return:
{
"type": "https://api.example.com/problems/user-not-found",
"title": "User not found",
"status": 404,
"detail": "User 123 does not exist"
}
The main value of the RFC is not the field names themselves, but the shared convention between APIs, clients, SDKs, and documentation.
status describes the HTTP-level error, type identifies the specific kind of problem, title provides a short description, and detail contains information about this particular occurrence.
The format is also extensible: you can add fields such as code, traceId, validation errors, or other domain-specific data.
RFC 9457 does not define your entire error model for you. It simply provides a solid standard foundation on top of which you can build your own conventions.
For a new HTTP API, it is one of those standards that is usually easier to adopt from the start than to invent a custom error format later.