Problem Details for HTTP APIs

Problem Details for HTTP APIs, first defined in RFC 7807 and now carried forward by RFC 9457, gives HTTP APIs a single, predictable shape for their error responses. Instead of every provider inventing its own error envelope, a problem is returned as application/problem+json (or +xml) with a small, well-known set of fields that both humans and machines can read. It is the difference between an error a client can program against and a blob of prose it has to guess at.

• A registered media type - application/problem+json signals a structured problem, not just any JSON body.
• Standardized members - type, title, status, detail, and instance describe what went wrong and where, consistently across endpoints.
• Extensibility - Providers can add domain-specific members alongside the standard ones without breaking consumers.
• A dereferenceable type URI - The type field points at documentation for the error class, so clients can learn more.
• Framework support - Spring, ASP.NET, and other stacks emit problem+json natively, making adoption cheap.

In real API operations this format is what turns error handling from a per-provider guessing game into something you can govern and automate. I can lint for it with Spectral, describe it in OpenAPI responses, and reason about failures the same way across a whole estate. For agents and other automated consumers, a consistent problem body is the signal they need to retry, escalate, or explain a failure without bespoke parsing per API. See the current revision under Problem Details (RFC 9457).