Before winding up this chapter, let's take a quick look at the life cycle of the JAX-RS components on the server when a client makes a RESTful web API call. This discussion would be a good summary of the topics that we learned so far on JAX-RS.

The following diagram depicts the sequence of actions taking place on the server when a client invokes the JAX-RS RESTful web service:

For an incoming REST API call, the container identifies the Java servlet configured for handling the REST API calls by parsing the URI, and then delegates the request to the designated servlet. The servlet initializes the JAX-RS runtime and kicks off the RESTful web service request processing cycle for the REST API call in the following sequence:

1. The runtime executes prematching filters (ContainerRequestFilter with the @Prematching annotation), which happens before resolving the resource method. The prematching filters are useful if you want to influence resource method resolution. The next step is to identify the resource method for serving the request.
2. After the resolution of the resource method, postmatching filters are executed (filters without @Prematching). Postmatching filters are useful for performing an authentication check or for performing a basic sanity check on the request parameters.
3. After executing all filters, the JAX-RS runtime invokes ReaderInterceptor. The reader interceptors are useful for manipulating the inbound request stream. A common use case may be to unzip the compressed stream before converting it into Java objects.

4. The next phase in the cycle is to convert the inbound stream into the Java object representation. This is done by matching the MessageBodyReader provider identified by the runtime.
5. After taking the incoming request through the configured filters, interceptors, and message body readers, the JAX-RS runtime invokes the resource class method identified for serving the request. If you have any Bean Validation annotation configured on the method parameters, it will get executed at this stage:
   1. If the validation fails and results in ConstraintViolationException, the runtime skips the execution of the method and identifies ExceptionMapper to handle the exception. The exception mapper generates the HTTP response content for the exception.
   2. Upon successful validation, the resource method is executed. If the resource method throws some exception, the framework invokes the matching ExceptionMapper to generate the HTTP response body for the exception.

6. The runtime takes the response content through the following stages before sending it to the client. The runtime executes ContainerResponseFilter, which can be used for adding the desired response header, such as cache parameters and content type.
7. The runtime executes WriterInterceptors for the response content. The interceptor class can hold logic for manipulating the response before sending it to the client, such as zipping the response body.
8. As the next step, the runtime invokes the appropriate MessageBodyWriter, which writes the Java type to an HTTP message to send it over HTTP. MessageBodyWriter can optionally amend or add the HTTP response headers. For instance, 200 OK is added to the response header if the method execution went well and returned an object. If the method is void, 204 No Content is set.
9. Once the response is ready, the container passes the response back to the client.