JAX-RS components can access this information through the request life cycle

Question

Looking through the request processing in JAX-RS, I learned that the flow of the whole process is as follows:

I know that there are different components that serve to connect, for example, we can have filters and connect them to any resource methods we want, the same thing happens with interceptors (and I know that they work around MessageBodyWriters and MessageBodyReaders ) But I am confused about each component and part of the information available to each component when the request goes through them,

The bottom line I learned is this:

---

Filters

Only headers can change (or must deal with). However, I saw the getEntityStream method in the ContainerRequestContext of the filter. Which thread is this method also referring to?

---

interceptors

Well, the only example I had was flashing a thread in some GzipReader (or something like that) over the Internet. Is this the only use of an interceptor? And I suspect that the entire request object is available in the interceptor, see Image below.

---

MessageBodyReader / Writers

They are understandable, and I think they have the same level of request information as is available to interceptors.

---

Question:

I did not understand what things each component can receive from an incoming request, and what should be changed in each of the components, well, this question can be broad, but a dedicated link to the solution of queries can be useful.

Edit:

Just tested. The filter can access the body of the message and can change it, so that the interceptor.: //

Answer 1

Let me start with Filters:

FILTERS:

Filters can modify incoming and outgoing requests and responses, including modifying headers, objects, and other request / response parameters.

Additional filters are classified as Container / Server Filters and Client Filters .

Consider server filters. There are two more obvious types:

• query filter
• response filter

There are two main differences between the two types (depending on what they refer to):

• Response filters implement the ContainerResponseFilter interface and have two arguments:

container request (ContainerRequestContext requestContext) and

container response (ContainerResponseContext responseContext) .

Now, what do these two arguments relate to:

public interface ContainerRequestContext

Container request filter context. A mutable class that provides information for a particular query for a filter, such as a query URI, message headers, a message object, or query scope properties. Open setters allow modification of the open information requested for a request.

public interface ContainerResponseContext

Context filter. A mutable class that provides response-specific information for a filter, such as message headers, a message object, or request scope properties. Open setters allow you to change the information specific to a specific user.

Note that requestContext can access one more thing: requestURI

2. Request filters are implemented by ContainerRequestFilter and have only one argument:

container request (ContainerRequestContext requestContext)

---

Getting to your question:

What stream is specified in the setEntityStream (arg0) and getEntityStream () method?

This can be broken down into:

• getEntityStream (): A server-side entity stream request is where the object is read from the client request and a client-side response object stream where the object is read from the server response.
• setEntityStream (arg0): On the server, when writing the response object and on the write request side, the request object for sending the request to the server for the write object. **

EDIT:

• Filters can be used to check certain criteria for any query. If the criteria are not met, filters can also cancel the response.

Consider the following example from the jersey documentation :

 public class AuthorizationRequestFilter implements ContainerRequestFilter { @Override public void filter(ContainerRequestContext requestContext) throws IOException { final SecurityContext securityContext = requestContext.getSecurityContext(); if (securityContext == null || !securityContext.isUserInRole("privileged")) { requestContext.abortWith(Response .status(Response.Status.UNAUTHORIZED) .entity("User cannot access the resource.") .build()); } } } 

The AuthorizationRequestFilter in this example checks to see if the authenticated user is in a privileged role. When the filter method is completed, the response passed as a parameter to the abortWith method is used to respond to the request. Response filters, if registered, will be executed and will be able to process a canceled response.

2. Filters can influence which method is consistent. Pre-match filters are query filters that run before query matching begins.

    @PreMatching public class PreMatchingFilter implements ContainerRequestFilter { @Override public void filter(ContainerRequestContext requestContext) throws IOException { // change all PUT methods to POST if (requestContext.getMethod().equals("PUT")) { requestContext.setMethod("POST"); } } } 

PreMatchingFilter is a simple pre-approval filter that changes all HTTP PUT methods to POST. This can be useful when you want to always process these PUT and POST HTTP methods with the same Java code.

---

Interceptors:

Write-Interceptors wraps the object in the GZIPOutput stream, and Reader-Interceptors wraps the object in the GZIPInput stream, which decompresses the data from the received compressed object.

In addition, Interceptors can also be used to provide digital signatures . For digital signatures, it is necessary to calculate the hash of the body and add it to the header of the request for signature (client-side) or response (server-side).

Answer 2

The jersey documentation is a good starting point to learn more about the JAX-RS API:

JAX-RS Filters

See what the filters documentation says:

Filters can be used if you want to change any request or response parameters, such as headers. For example, you would like to add an X-Powered-By response header to each generated response. Instead of adding this header to each resource method, you should use a response filter to add this header.

There are filters on the server side and on the client side.

Server Filters:

• ContainerRequestFilter
• ContainerResponseFilter

Client Filters:

• ClientRequestFilter
• ClientResponseFilter

According to the filter, you are provided with request / response context objects that allow you to change the requested method, the requested URI, headers, response status code, etc. And you can also access a thread that allows you to manipulate the request / response payload.

While ContainerRequestContext and ContainerResponseContext are available on the server, ClientRequestContext and ClientResponseContext are available on the client.

JAX-RS Interceptors

See what the documentation for interceptors says:

Interceptors use a common API for the server and client side. While filters are mainly designed to manipulate request and response parameters, such as HTTP headers, URIs and / or HTTP methods, interceptors are designed to control objects by controlling the input / output streams of the object. If, for example, you need to encode the body of a client request object, then you can implement an interceptor to perform this work for you.

There are two types of interceptors: ReaderInterceptor and WriterInterceptor .

Reader-interceptors are used to control incoming streams of entities. These are streams coming from the "wire". Thus, using the reader-interceptor, you can manipulate the flow of the request entity on the server side (where the object is read from the client request) and the flow of the response object on the client side (where the object is read from the server response).

Writer interceptors are used for cases when the object is written to the "wire", which on the server means when recording the response object and on the client side when writing the request object to send a request to the server.

Writing and reading interceptors are performed before readers or writers of the message body are executed, and their main intention is to wrap the streams of entities that will be used in the reader and message writers.

[...]

Interceptors provide you with context objects so that you can access request / response payload streams. Additonaly, you can access a mutable map that allows you to manipulate request / response headers.

ReaderInterceptorContext and WriterInterceptorContext are available both on the client and on the server.