Java Reference
In-Depth Information
response
.
setStatus
(
200
);
response
.
getHeaders
().
putSingle
(
"Content-Type"
,
entry
.
getContentType
());
ByteArrayInputStream is
=
new
new
ByteArrayInputStream
(
entry
.
getContent
());
response
.
setInputStream
(
is
);
}
}
}
The
CacheResponseFilter.filter()
method starts off by checking if the invoked request
was an HTTP GET. If not, it just returns. If the response status was 200, “OK,” then we ask
the
Cache
object to cache the response for the specific request URI. The
Cache.cacheResponse()
method is responsible for buffering the response and storing relev-
ant response headers and the message body. For brevity's sake, I'm not going to go into the
details of this method. If instead the response code is 304, “Not Modified,” this means that
we have performed a successful conditional GET. We update the cache entry with any
ETag
or
Last-Modified
response headers. Also, because the response will have no message body,
we must rebuild the response based on the cache entry. We clear all the headers from
Cli-
entResponseContext
and set the appropriate
Content-Type
. Finally we override the re-
sponse's
InputStream
with the buffer stored in the cache entry.
Deploying Filters and Interceptors
On the server side, filters and interceptors are deployed the same way any other
@Provider
is deployed. You either annotate it with
@Provider
and let it be scanned and automatically
registered, or you add the filter or interceptor to the
Application
class's classes or
singletons list.
On the client side, you register filters and interceptors the same way you would register any
other provider. There are a few components in the Client API that implement the
Configur-
able
interface. This interface has a
register()
method that allows you to pass in your filter
or interceptor class or singleton instance.
ClientBuilder
,
Client
, and
WebTarget
all im-
plement the
Configurable
interface. What's interesting here is that you can have different
filters and interceptors per
WebTarget
. For example, you may have different security re-
quirements for different HTTP resources. For one
WebTarget
instance, you might register a
Basic Auth filter. For another, you might register a token filter.
Ordering Filters and Interceptors
When you have more than one registered filter or interceptor, there may be some sensitivities
on the order in which these components are executed. For example, you usually don't want
