The framework uses container request filters, which are executed before the resource method is invoked. Pre-matching request filters are called before a suitable resource method has been found for the resource, allowing you to identify which method is matched for the HTTP request. Post-matching request filters are run after a method has been matched for the resource and enable you to stop a request before the resource method is invoked.
The Jersey servlet references the JAXRSContextPreMatchRequestFilter, which is an implementation of a pre-match filter request. This filter initializes a RestContext instance for the request, which is a holder class that keeps data that has been gathered during the processing of the request. The RestContext instance is kept in a thread-local stack that can be accessed statically. The filter also provides support for tunneling using the x-http-method-override header, which allows a client to specify the HTTP method that the server should use for the request regardless of the actual request HTTP method. This filter sets the value as the HTTP method in context. This allows clients who may be restricted in the HTTP methods they can use for a request to still invoke other endpoints. For example, if a client can only issue GET and POST requests, they could issue a POST request with the x-http-method-override = "PATCH" to invoke a patch-based endpoint.
The JAXRSContextPostMatchingRequestFilter, which is the first post-matching filter called by Jersey, populates the current RestContext with details of the resource that matched the request and populates its filter properties if any applicable query parameters have been passed in by the client. It is executed after the resource method has been selected and sets up the current RestContext for the matched resource.
The SecurityPostMatchRequestFilter, which runs after the JAXRSContextPostMatchingRequestFilter, invokes the access control for the request URI and HTTP method and rejects the request if access is denied. If access is denied, an exception is thrown with the appropriate response code.
Once the request security has been verified, the CachePostMatchRequestFilter component performs validation on the request. By default, this Nucleus component is configured with a set of validators that include XSS checks and asset language checks. If locking is enabled for the resource, the CachePostMatchRequestFilter acquires a lock for the resource. This filter also provides Etag pre-condition support for the If-Match header. If the request is a GET request and there is a server-side cached response available that matches the request, the response is returned to the client and processing ends.
The CachePostMatchRequestFilter uses either the JSONMessageBodyReader or the HALMessageBodyReader to read the request header. The HALMessageBodyReader is used when the content-type header is application/hal+json; otherwise the JSONMessageBodyReader is used.
