Every API has errors. But every API should not invent its own error shape. 😅
RFC 9457 defines a standard way to describe HTTP API errors with application/problem+json.
Instead of returning random payloads like:
{ "error": "Something failed" }
you expose a predictable structure:
{ "type": "urn:problem-type:validation-error", "title": "Validation Failed", "status": 400, "detail": "The request body or parameters failed validation." }
🔸 TL;DR
▪️ Clients already know how to parse the format.
▪️ Gateways, SDKs, logs, and tracing tools can handle errors more consistently.
▪️ You can extend the response without breaking clients.
▪️ type identifies the error category.
▪️ detail explains what happened this time.
In Jakarta EE, you can implement it with a small ProblemDetail class and ExceptionMappers.
Or use alternatives depending on your stack:
▪️ Jakarta EE portable approach: handmade ProblemDetail
▪️ Zalando Problem: reusable model + Jackson support
▪️ Quarkus: quarkus-http-problem
▪️ Spring Boot 3+: built-in ProblemDetail
🔸 TAKEAWAYS
▪️ Error handling is part of API design.
▪️ Standard envelopes reduce client-side special cases.
▪️ A catch-all mapper helps avoid leaking stack traces.
▪️ Frameworks differ, but the payload should stay predictable.
▪️ The goal is not one implementation.
The goal is one understandable contract.
Clean APIs also fail cleanly. ✅
#Java #JakartaEE #JAXRS #APIDesign #REST #RFC9457 #ProblemDetails #SpringBoot #Quarkus #MicroProfile #SoftwareArchitecture
Go further with Java certification:
Java👇
Spring👇
SpringBook👇
JavaBook👇