Article

Handling Exception Scenarios in REST API developed using JAX-RS

October 2, 2017
Java Microservices
Author photo: Rahul Kumar
Rahul Kumar

Prerequisite: Hands on Knowledge of REST API Development using JAX-RS.

REST Services has been an integral part of complex enterprise applications for several years. Developers generally prefer two APIs listed below for building REST API in their enterprise applications.

  1. JAX-RS – Part of JEE Specification with different implementations like RestEasy, Jersey, Restlet etc.
  2. Spring Boot – An OpenSource Spring Community Project best suited for Microservices-based applications.

In this Article, we will learn how to handle Exceptions gracefully in Rest APIs which are built using JAX-RS.

Example

Lets take an example of an Social Media application like Twitter, deployed in some Application/Web server like Tomcat. A sample REST Endpoint in Twitter API could be like so:

/tweet/{tweetID}
// Gives Client a particular tweet based on tweet ID provided.

Now what if the Client sends a tweetID for which there is no tweet available in database. For example:

/tweet/25
// no content(as Response)

It's not something that the Client of the Rest Service wants to see. In such cases, we can create our own custom exceptions. This way, if someone tries to access a tweet that's not available in server, we simply throw an exception rather return empty content.

STEP 1: Create Custom Exception

public class INFONotFoundException extends RuntimeException {
    private static final long serialVersionUID = 1L;

    public INFONotFoundException(String message) {
        super(message);
    }
}

Now if we access /tweet/25 but the particular tweet ID isn't available, we get the Tomcat Error Page because we are throwing INFONotFoundException in our business class but not catching it. It bubbles up in JAX_RS, which also doesn't know what to do with this exception, so it goes up to servlet container which has a default behavior to show standard error page in case something wrong happened in server side code.

We don't want an HTML error Page for the exception as the response of Rest API End Point, though. We want a JSON payload as the response so it is useful to the client who is consuming the REST API, so they can parse it accordingly. For this, we would like JAX-RS framework to catch it and return a JSON payload before it goes up to servlet container.

STEP 2:  Map Custom Exception to JSON Payload(e.g ErrorResponse) using JAX-RS ExceptionMapper

public class ErrorResponse {
  String errorMessage;
  String errorCode;
  String documentationLink;
  
  public ErrorResponse(String errorMessage, String errorCode, String documentationLink) {
    super();
    this.errorMessage = errorMessage;
    this.errorCode = errorCode;
    this.documentationLink = documentationLink;
  }
  
  public ErrorResponse() {
  
  }
  // Getters and Setters
}
@Provider
public class INFONotFoundExceptionMapper implements ExceptionMapper<INFONotFoundException> {
  @Override
  public Response toResponse(INFONotFoundException ex) {
    ErrorResponse response = new ErrorResponse(ex.getMessage(), "503",
      "https://docs.oracle.com/javaee/7/api/javax/ws/rs/ext/ExceptionMapper.html");
    return Response.ok().entity(response).build();
  }
}

Now, when JAX-RS sees any INFONotFoundException in the application, it searches all ExceptionMapper's annotated with @Provider in application and tries to find a mapper which could map the INFONotFoundException to a ErrorResponse. Once it finds a suitable ExceptionMapper, it passes the thrown Exception to the method argument of toResponse(Exception ex) in ExceptionMapper and builds a JSON payload by calling toResponse(Exception e) method of ExceptionMapper.

Now, the client does not see an HTML error page anymore and JAX-RS gives a nice JSON payload which can help the client with troubleshooting.

Note:

1. We can include ExceptionMapper in our REST API in order to address specific Exceptions to be more helpful to the client.

2. It's always good practice to create a generic ExceptionMapper in case the developer doesn't want to create multiple mappers for each exception thrown in application. This way, no matter what goes wrong in our server side REST API (e.g NullPointerException, DataNotFoundException, etc.), JAX-RS always tries to map it with GenericExceptionMapper and we never see the HTML Error page but instead a JSON payload which can be helpful for the service client.

@Provider
public class GenericExceptionMapper implements ExceptionMapper<Throwable> {
  
  @Override
  public Response toResponse(Throwable arg0) {
    // TODO Auto-generated method stub
    return null;
  }
}
Last updated: June 8, 2021

Comments