One area of the RESTful web APIs design, quite frequently overlooked, is how to report errors and problems, either related to business or application. The proper usage of the HTTP status codes comes to mind first, and although quite handy, often it is not informative enough. Let us take 400 Bad Request for example. Yes, it clearly states that the request is problematic, but what exactly is wrong?
The RESTful architectural style does not dictate what should be done in this case and so everyone is inventing its own styles, conventions and specifications. It could be as simple as including error message into the response or as shortsighted as copy/pasting long stack traces (in case of Java or .NET, to name a few cultprits). There is no shortage of ideas but luckily, we have at least some guidance available in the form of RFC 7807: Problem Details for HTTP APIs. Despite the fact that it is not an official specification but a draft (still), it outlines the good common principles on the problem at hand and this is what we are going to talk about in this post.
In the nutshell, RFC 7807: Problem Details for HTTP APIs just proposes the error or problem representation (in JSON or XML formats) which may include at least the following details:
- type - A URI reference that identifies the problem type
- title - A short, human-readable summary of the problem type
- status - The HTTP status code
- detail - A human-readable explanation specific to this occurrence of the problem
- instance - A URI reference that identifies the specific occurrence of the problem
Our imaginary People Management web API is going to be built using the state of the art technology stack, Spring Boot and Apache CXF, the popular web services framework and JAX-RS 2.1 implementation. To keep it somewhat simple, there are only two endpoints which are exposed: registration and lookup by person identifier.
Sweeping aside the tons of issues and business constraints you may run into while developing the real-world services, even with this simple API a few things may go wrong. The first problem we age going to tackle is what if the person you are looking for is not registered yet? Looks like a fit for 404 Not Found, right? Indeed, let us start with our first problem, PersonNotFoundProblem!
public class PersonNotFoundProblem extends AbstractThrowableProblem {
private static final long serialVersionUID = 7662154827584418806L;
private static final URI TYPE = URI.create("http://localhost:21020/problems/person-not-found");
public PersonNotFoundProblem(final String id, final URI instance) {
super(TYPE, "Person is not found", Status.NOT_FOUND,
"Person with identifier '" + id + "' is not found", instance,
null, Map.of("id", id));
}
}
It resembles a lot the typical Java exception, and it really is one, since AbstractThrowableProblem is the subclass of the RuntimeException. As such, we could throw it from our JAX-RS API.
@Produces({ MediaType.APPLICATION_JSON, "application/problem+json" })
@GET
@Path("{id}")
public Person findById(@PathParam("id") String id) {
return service
.findById(id)
.orElseThrow(() -> new PersonNotFoundProblem(id, uriInfo.getRequestUri()));
}
If we run the server and just try to fetch the person providing any identifier, the problem detail response is going to be returned back (since the dataset is not pre-populated), for example:
$ curl "http://localhost:21020/api/people/1" -H "Accept: */*"
HTTP/1.1 404
Content-Type: application/problem+json
{
"type" : "http://localhost:21020/problems/person-not-found",
"title" : "Person is not found",
"status" : 404,
"detail" : "Person with identifier '1' is not found",
"instance" : "http://localhost:21020/api/people/1",
"id" : "1"
}
Please notice the usage of the application/problem+json media type along with additional property id being included into the response. Although there are many things which could be improved, it is arguably better than just naked 404 (or 500 caused by EntityNotFoundException). Plus, the documentation section behind this type of the problem (in our case, http://localhost:21020/problems/person-not-found) could be consulted in case further clarifications may be needed.
So designing the problems after exceptions is just one option. You may often (and for very valid reasons) restrain from coupling you business logic with unrelated details. In this case, it is perfectly valid to return the problem details as the response payload from the JAX-RS resource. As an example, the registration process may raise NonUniqueEmailException so our web API layer could transform it into appropriate problem detail.
@Consumes(MediaType.APPLICATION_JSON)
@Produces({ MediaType.APPLICATION_JSON, "application/problem+json" })
@POST
public Response register(@Valid final CreatePerson payload) {
try {
final Person person = service.register(payload.getEmail(),
payload.getFirstName(), payload.getLastName());
return Response
.created(uriInfo.getRequestUriBuilder().path(person.getId()).build())
.entity(person)
.build();
} catch (final NonUniqueEmailException ex) {
return Response
.status(Response.Status.BAD_REQUEST)
.type("application/problem+json")
.entity(Problem
.builder()
.withType(URI.create("http://localhost:21020/problems/non-unique-email"))
.withInstance(uriInfo.getRequestUri())
.withStatus(Status.BAD_REQUEST)
.withTitle("The email address is not unique")
.withDetail(ex.getMessage())
.with("email", payload.getEmail())
.build())
.build();
}
}
To trigger this issue, it is enough to run the server instance and try to register the same person twice, like we have done below.
$ curl -X POST "http://localhost:21020/api/people" \
-H "Accept: */*" -H "Content-Type: application/json" \
-d '{"email":"john@smith.com", "firstName":"John", "lastName": "Smith"}'
HTTP/1.1 400
Content-Type: application/problem+json
{
"type" : "http://localhost:21020/problems/non-unique-email",
"title" : "The email address is not unique",
"status" : 400,
"detail" : "The email 'john@smith.com' is not unique and is already registered",
"instance" : "http://localhost:21020/api/people",
"email" : "john@smith.com"
}
Great, so our last example is a bit more complicated but, probably, at the same time, the most realistic one. Our web API heavily relies on Bean Validation in order to make sure the input provided by the consumers of the API is valid. How would we represent the validation errors as the problem details? The most straightforward way is to supply the dedicated ExceptionMapper provider, which is the part of the JAX-RS specification. Let us introduce one.
@Provider
public class ValidationExceptionMapper implements ExceptionMapper<ValidationException> {
@Context private UriInfo uriInfo;
@Override
public Response toResponse(final ValidationException ex) {
if (ex instanceof ConstraintViolationException) {
final ConstraintViolationException constraint = (ConstraintViolationException) ex;
final ThrowableProblem problem = Problem
.builder()
.withType(URI.create("http://localhost:21020/problems/invalid-parameters"))
.withTitle("One or more request parameters are not valid")
.withStatus(Status.BAD_REQUEST)
.withInstance(uriInfo.getRequestUri())
.with("invalid-parameters", constraint
.getConstraintViolations()
.stream()
.map(this::buildViolation)
.collect(Collectors.toList()))
.build();
return Response
.status(Response.Status.BAD_REQUEST)
.type("application/problem+json")
.entity(problem)
.build();
}
return Response
.status(Response.Status.INTERNAL_SERVER_ERROR)
.type("application/problem+json")
.entity(Problem
.builder()
.withTitle("The server is not able to process the request")
.withType(URI.create("http://localhost:21020/problems/server-error"))
.withInstance(uriInfo.getRequestUri())
.withStatus(Status.INTERNAL_SERVER_ERROR)
.withDetail(ex.getMessage())
.build())
.build();
}
protected Map<?, ?> buildViolation(ConstraintViolation<?> violation) {
return Map.of(
"bean", violation.getRootBeanClass().getName(),
"property", violation.getPropertyPath().toString(),
"reason", violation.getMessage(),
"value", Objects.requireNonNullElse(violation.getInvalidValue(), "null")
);
}
}
The snippet above distingushes two kind of issues: the ConstraintViolationExceptions indicate the invalid input and are mapped to 400 Bad Request, whereas generic ValidationExceptions indicate the problem on the server side and are mapped to 500 Internal Server Error. We only extract the basic details about violations, however even that improves the error reporting a lot.
$ curl -X POST "http://localhost:21020/api/people" \
-H "Accept: */*" -H "Content-Type: application/json" \
-d '{"email":"john.smith", "firstName":"John"}' -i
HTTP/1.1 400
Content-Type: application/problem+json
{
"type" : "http://localhost:21020/problems/invalid-parameters",
"title" : "One or more request parameters are not valid",
"status" : 400,
"instance" : "http://localhost:21020/api/people",
"invalid-parameters" : [
{
"reason" : "must not be blank",
"value" : "null",
"bean" : "com.example.problem.resource.PeopleResource",
"property" : "register.payload.lastName"
},
{
"reason" : "must be a well-formed email address",
"value" : "john.smith",
"bean" : "com.example.problem.resource.PeopleResource",
"property" : "register.payload.email"
}
]
}
This time the additional information bundled into the invalid-parameters member is quite verbose: we know the class (PeopleResource), method (register), the method's argument (payload) and the properties (lastName and email) respectively (all that extracted from the property path).
Meaningful error reporting is one of corner stones of the modern RESTful web APIs. Often it is not easy but definitely worth the efforts. The consumers (which often are just other developers) should have a clear understanding of what went wrong and what to do about it. The RFC 7807: Problem Details for HTTP APIs is a step into right direction and libraries like problem and problem-spring-web are here to back you up, please make use of them.
The complete source code is available on Github.
Posts
