SYSTEM
RFC 7807 — Problem Details for HTTP API¶
Definition¶
RFC 7807 is an IETF standard (Nottingham & Wilde, 2016) that defines a canonical JSON shape for expressing errors in HTTP APIs. Rather than each service inventing its own error envelope, clients can rely on a small, discoverable set of well-known members:
| Member | Purpose |
|---|---|
type |
URI identifying the problem type |
title |
short, human-readable summary |
status |
the original HTTP status code |
detail |
human-readable explanation specific to this occurrence |
instance |
URI identifying this specific occurrence |
The media type is application/problem+json (or
application/problem+xml).
Why it matters outside HTTP¶
Although the RFC is scoped to HTTP APIs, the vocabulary
Problem Details has been adopted in other API substrates
to name the same structural concern: an error as a
first-class, typed payload, distinct from an exception or
bug. Zalando's 2021 GraphQL errors post cites RFC 7807
explicitly as the source for calling schema-modelled
errors Problems (not Errors):
"There is a well-defined concept in RFC 7807 - Problem details for HTTP API. So, we will call all our errors in Schema as Problems and, as it has always been, all other errors as errors."
This naming choice avoids colliding with GraphQL's reserved
error keyword (response.errors) while borrowing an
industry-standard term.
Design principles the RFC imports¶
- Extensibility by design. The object may carry
additional members beyond the standard ones, enabling
structured per-domain extensions (e.g.
invalidInputs: [...]). - URI-based problem type identity. The
typefield is a URI so two different services can share a problem-type identity (and so clients can dereference for documentation). - Distinction between problem type and occurrence.
typeidentifies the kind of problem;instanceidentifies the specific occurrence. This matches how Zalando's Problem types work in GraphQL: the union member identifies the kind; fields on the member identify the occurrence.
In the wiki¶
- Used by Zalando's UBFF GraphQL — see systems/zalando-graphql-ubff and the error-modeling discipline in patterns/problem-type-for-customer-actionable-errors.
- The name-split rationale is captured in concepts/problem-vs-error-distinction.
Seen in¶
Related¶
- systems/graphql — the substrate that imports the naming for non-HTTP API errors
- concepts/problem-vs-error-distinction
- patterns/problem-type-for-customer-actionable-errors