The reader interceptors manage the reader interceptor context. This context lets you manage the following things:

• Headers
• Input stream

See an example of interceptor that manipulates the input stream of a POST method call:

@Provider
@ConstrainedTo(SERVER)
@Priority(ENTITY_CODER + 30)
public class ServerReaderInterceptor implements ReaderInterceptor {
   @Override
   public Object aroundReadFrom(ReaderInterceptorContext interceptorContext) throws IOException, WebApplicationException {
      InputStream inputStream = interceptorContext.getInputStream();
      byte[] bytes = new byte[inputStream.available()];
      inputStream.read(bytes);
      String requestContent = new String(bytes);
      requestContent = requestContent + ".Request changed in ServerReaderInterceptor.";
      interceptorContext.setInputStream(new ByteArrayInputStream(requestContent.getBytes()));
      return interceptorContext.proceed();
   }
}

This interceptor catches the input stream and appends a text. At difference of the filters that work for a particular runtime scope, the interceptors are configurable through the @ConstrainedTo annotation, where you can specify the runtime scope CLIENT or SERVER through the enum javax.ws.rs.RuntimeType. If the @ConstrainedTo is not declared, the component will work both as a client and server.

The registration of the interceptor follows the same specifications seen in the filter according to the declared runtime scope. A server interceptor marked as @Provider doesn't need to be registered to work.

The proceed method lets us go to the next interceptor of the chain.