Map standard and custom exceptions to a http response body containing problem details as specified in RFC-9457 (formerly RFC-7807).

Most things work out of the box: the type and title fields are derived from the exception class name; the detail field is the message of the exception; the instance field is a random UUID URN that is also logged together with the complete stack trace.

These defaults and the status code can be overridden with annotations.

I wrote a blog about this.

Getting a consistent error response format for a REST API is a common problem and allows clients to handle specific business errors. Getting some generic HTML response is not helpful. There is a standard for this type of details about an error: RFC-9457. And this library provides a simple way to map exceptions to this format.

This has been proposed to and rejected by several existing specs:

• Jakarta REST (JAX-RS); a second discussion was also rejected.

• MP REST Client.

The API in the api module looks quite stable. Some first ideas for a full spec follow below. It’s yet far from complete, but it’s a start:

• MUST application/problem+json, application/problem+xml; SHOULD any, e.g. +yaml

• SHOULD render text/html

• map also @Valid REST params

• logging: 4xx = DEBUG, 5xx = ERROR; configurable?

• order of extensions is alphabetic (which is better for tests than random)

• multiple extensions with the same name: undefined behavior

• JAXB can’t unmarshal a subclass with the same type and namespace

• Security considerations: nothing dangerous in problem details (i.e. exception message); stack-trace in logs

• TODO scan client classpath for @Type annotated exceptions (and document this in the spec and the annotation)

• TODO inherited annotations

• TODO cause annotations

• TODO type factory, e.g. URL to OpenAPI

• TODO instance factory, e.g. URL to the logging system filtering on an UUID

It’s called ri, but it’s actually only a POC, and it’s incomplete. See the README for details.

The test module runs integration tests by using JEE Testcontainers, i.e. it can be configured to start different Docker containers with various JEE application servers. By default, it starts a Wildfly.

testcontainer-running

As the containers don’t yet implement the API by themselves, the dummy implementation ri is hard-wired in the tests for now.

We build for JDK 11 and the Jakarta EE 10 APIs. The current versions of Spring Boot don’t support this combination. But you can still use the older com.github.t1:problem-details-api:1.0.10, which was based on Jakarta EE 8.