Java Reference
In-Depth Information
once within the small window of validity. So, even if you have dynamic web services, there's
still a good chance that web caching is viable for these services.
HTTP Caching
Before we can leverage web caching, proxy caches, and CDNs for our web services, we need
to understand how caching on the Web works. The HTTP protocol defines a rich set of built-
in caching semantics. Through the exchange of various request and response headers, the
HTTP protocol gives you fine-grained control over the caching behavior of both browser and
proxy caches. The protocol also has validation semantics to make managing caches much
more efficient. Let's dive into the specifics.
Expires Header
How does a browser know when to cache? In HTTP 1.0, a simple response header called
Ex-
pires
tells the browser that it can cache and for how long. The value of this header is a date
in the future when the data is no longer valid. When this date is reached, the client should no
longer use the cached data and should retrieve the data again from the server. For example, if
a client submitted
GET /customers/123
, an example response using the
Expires
header
would look like this:
HTTP
HTTP
/
1.1 200
OOK
Content-Type
:
application/xml
Expires: Tue, 15 May 2014 16:00 GMT
<customer id="123">...</customers>
This cacheable XML data is valid until Tuesday, May 15, 2014.
We can implement this within JAX-RS by using a
javax.ws.rs.core.Response
object. For
example:
@Path
(
"/customers"
)
public
public class
class
CustomerResource
CustomerResource
{
@Path
(
"{id}"
)
@GET
@Produces
(
"application/xml"
)
public
public
Response
getCustomer
(
@PathParam
(
"id"
)
int
int
id
) {
Customer cust
=
findCustomer
(
id
);
ResponseBuilder builder
=
Response
.
ok
(
cust
,
"application/xml"
);
Date date
=
Calendar
.
getInstance
(
TimeZone
.
getTimeZone
(
"GMT"
))
.
set
(
2010
,
5
,
15
,
16
,
0
);
builder
.
expires
(
date
);
