Problem-Detail-Antworten nach RFC 7807
Standardisieren Sie maschinenlesbare Fehler-Payloads mit Spring-ProblemDetail und der Unterstützung durch ErrorResponse.
Problem-Detail-Antworten nach RFC 7807 ist eine kostenlose Spring Boot 4 Complete Guide-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Spring Boot 4 Complete Guide-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Spring Boot 4 Complete Guide-Kurs umfasst insgesamt 4 Lektionen.
Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.
Why Standardize Error Responses?
When an API fails, clients need a predictable, machine-readable error body. Hand-rolled JSON like {"error": "bad"} varies per endpoint and breaks integrations.
RFC 7807 ("Problem Details for HTTP APIs") defines a single, standard shape for error payloads. Spring Boot has first-class support for it through the ProblemDetail class and the ErrorResponse contract.
- Consistent across every endpoint
- Self-documenting via a
typeURI - Extensible with custom properties
The RFC 7807 Media Type and Fields
A Problem Detail response uses the media type application/problem+json and contains these standard members:
- type — a URI identifying the problem category (defaults to
about:blank) - title — a short, human-readable summary
- status — the HTTP status code (e.g. 404)
- detail — a human-readable explanation specific to this occurrence
- instance — a URI identifying the specific occurrence (often the request path)
You may also add custom extension members like errorCode or timestamp.
A Sample Problem+JSON Body
Here is what a client actually receives. Note the application/problem+json content type and the standard fields, plus an extension member errorCode.
{
"type": "https://api.shop.com/problems/out-of-stock",
"title": "Out of Stock",
"status": 409,
"detail": "Product 42 has only 3 units left, but 5 were requested.",
"instance": "/api/orders",
"errorCode": "INVENTORY_SHORTAGE"
}Building a ProblemDetail Programmatically
Spring's ProblemDetail is a simple value object. Use the static factory forStatus() or forStatusAndDetail(), then enrich it with setters.
You can attach custom members via setProperty(name, value). This object serializes directly to application/problem+json.
ProblemDetail problem = ProblemDetail.forStatusAndDetail(
HttpStatus.NOT_FOUND,
"Product 42 was not found");
problem.setTitle("Product Not Found");
problem.setType(URI.create("https://api.shop.com/problems/not-found"));
problem.setInstance(URI.create("/api/products/42"));
problem.setProperty("errorCode", "PRODUCT_NOT_FOUND");Returning ProblemDetail from a Controller
A controller method can return a ProblemDetail directly, or wrap it in a ResponseEntity for full control of headers. Spring sets the status from the ProblemDetail and serializes the body as problem+json.
@GetMapping("/products/{id}")
public ResponseEntity<ProblemDetail> getProduct(@PathVariable Long id) {
return productRepo.findById(id)
.map(p -> ResponseEntity.ok().<ProblemDetail>build())
.orElseGet(() -> {
ProblemDetail pd = ProblemDetail.forStatusAndDetail(
HttpStatus.NOT_FOUND, "No product with id " + id);
pd.setTitle("Product Not Found");
return ResponseEntity.status(404).body(pd);
});
}The ErrorResponse Contract
Returning ProblemDetail manually works, but Spring prefers exceptions to carry their own problem detail. The ErrorResponse interface couples an HTTP status, headers, and a ProblemDetail body.
Spring MVC automatically renders any thrown exception that implements ErrorResponse as problem+json. The convenience class ErrorResponseException is a ready-made implementation you can throw directly.
ProblemDetail pd = ProblemDetail.forStatusAndDetail(
HttpStatus.CONFLICT, "Email already registered");
pd.setTitle("Duplicate Email");
pd.setProperty("errorCode", "DUPLICATE_EMAIL");
throw new ErrorResponseException(HttpStatus.CONFLICT, pd, null);Custom Exceptions Implementing ErrorResponse
For domain errors, implement ErrorResponse on your own exception. By extending ErrorResponseException, you inherit status, headers, and body handling, and just supply a configured ProblemDetail.
This keeps error definitions next to the domain logic and out of controllers.
public class OutOfStockException extends ErrorResponseException {
public OutOfStockException(long productId, int available, int requested) {
super(HttpStatus.CONFLICT, asProblemDetail(productId, available, requested), null);
}
private static ProblemDetail asProblemDetail(long id, int avail, int req) {
ProblemDetail pd = ProblemDetail.forStatusAndDetail(
HttpStatus.CONFLICT,
"Product " + id + " has only " + avail + " left, but " + req + " requested.");
pd.setType(URI.create("https://api.shop.com/problems/out-of-stock"));
pd.setTitle("Out of Stock");
pd.setProperty("errorCode", "INVENTORY_SHORTAGE");
return pd;
}
}Centralizing with @ControllerAdvice
The cleanest pattern: throw plain domain exceptions, then convert them to ProblemDetail in one place using @RestControllerAdvice and @ExceptionHandler.
The handler returns a ProblemDetail; Spring applies the status and problem+json content type automatically.
@RestControllerAdvice
public class GlobalExceptionHandler {
@ExceptionHandler(ProductNotFoundException.class)
public ProblemDetail handleNotFound(ProductNotFoundException ex) {
ProblemDetail pd = ProblemDetail.forStatusAndDetail(
HttpStatus.NOT_FOUND, ex.getMessage());
pd.setTitle("Product Not Found");
pd.setType(URI.create("https://api.shop.com/problems/not-found"));
pd.setProperty("errorCode", "PRODUCT_NOT_FOUND");
return pd;
}
}Extending ResponseEntityExceptionHandler
Spring's built-in exceptions (validation failures, unreadable bodies, missing parameters) are handled by ResponseEntityExceptionHandler. Since Spring Boot 3, these already produce ProblemDetail bodies.
Extend it in your advice to override or enrich the defaults while keeping framework error handling consistent.
@RestControllerAdvice
public class ApiExceptionHandler extends ResponseEntityExceptionHandler {
@Override
protected ResponseEntity<Object> handleMethodArgumentNotValid(
MethodArgumentNotValidException ex, HttpHeaders headers,
HttpStatusCode status, WebRequest request) {
ProblemDetail pd = ex.getBody();
pd.setTitle("Validation Failed");
pd.setProperty("errorCode", "VALIDATION_ERROR");
return handleExceptionInternal(ex, pd, headers, status, request);
}
}Adding Standard Extension Properties
Common extensions include a timestamp and a traceId for log correlation. Add them in one place so every error carries them.
Use setProperty with serializable values; Instant serializes to an ISO-8601 string by default.
ProblemDetail pd = ProblemDetail.forStatusAndDetail(
HttpStatus.BAD_REQUEST, "Quantity must be positive");
pd.setTitle("Invalid Quantity");
pd.setProperty("timestamp", Instant.now());
pd.setProperty("traceId", MDC.get("traceId"));
pd.setProperty("errorCode", "INVALID_QUANTITY");Configuring Defaults in application.yml
Spring can include extra context automatically. Enabling these properties makes the framework attach standard details without code changes.
spring.mvc.problemdetails.enabled=trueturns on problem+json for built-in exceptions (default in Boot 3+)server.error.include-messageandinclude-binding-errorscontrol how much detail is exposed
Keep sensitive details out of production responses by tuning these flags.
spring:
mvc:
problemdetails:
enabled: true
server:
error:
include-message: on_param
include-binding-errors: on_param
include-stacktrace: neverQuick Check: Choosing the Right Pattern
You have several domain exceptions (not-found, conflict, forbidden) and want every error across all controllers to emit consistent application/problem+json with shared extensions like traceId. What is the recommended Spring approach?
Recap: RFC 7807 in Spring Boot
You learned how to standardize error payloads with RFC 7807:
- ProblemDetail is the value object for
application/problem+json, withtype,title,status,detail,instanceplus custom properties. - ErrorResponse / ErrorResponseException let exceptions carry their own problem detail.
- @RestControllerAdvice centralizes conversion of domain exceptions into ProblemDetail.
- ResponseEntityExceptionHandler already renders Spring's built-in exceptions as problem+json, and can be extended.
- Add extensions like
errorCode,timestamp, andtraceId, and tune exposure viaapplication.yml.
The result: a single, predictable, machine-readable error contract across your whole API.
Lerne Java mit einem KI-Tutor — kostenlos
Schreibe und führe echten Code in deinem Browser aus, bekomme sofortige Hilfe von einem 24/7 KI-Tutor und setze dein Lernen im Web oder in der App fort.
- Kurse
- 21
- Lektionen
- 84
Häufig gestellte Fragen
Ist die Lektion „Problem-Detail-Antworten nach RFC 7807“ kostenlos?
Ja — der vollständige Text von „Problem-Detail-Antworten nach RFC 7807“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Spring Boot 4 Complete Guide-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Spring Boot 4 Complete Guide-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Problem-Detail-Antworten nach RFC 7807“?
Standardisieren Sie maschinenlesbare Fehler-Payloads mit Spring-ProblemDetail und der Unterstützung durch ErrorResponse. Du übst Spring Boot 4 Complete Guide mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um Spring Boot 4 Complete Guide zu starten?
Keine Vorkenntnisse erforderlich. Spring Boot 4 Complete Guide auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.
Wie lange dauert die Lektion „Problem-Detail-Antworten nach RFC 7807“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser Spring Boot 4 Complete Guide-Lektion Code schreiben und ausführen?
Ja. Jede Spring Boot 4 Complete Guide-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- Bean-Validation-Constraints und Constraint-Gruppen
- Benutzerdefinierte Constraint-Annotationen erstellen
- Globale Ausnahmebehandlung mit @ControllerAdvice
- Problem-Detail-Antworten nach RFC 7807