Java Reference
In-Depth Information
public
public
CustomerResource
(
Map
<
Integer
,
Customer
>
customerDB
)
{
this
this
.
customerDB
=
customerDB
;
}
@POST
@Consumes
(
"application/xml"
)
public
public
Response
createCustomer
(
InputStream is
) {
...
}
@GET
@Path
(
"{id}"
)
@Produces
(
"application/xml"
)
public
public
StreamingOutput
getCustomer
(
@PathParam
(
"id"
)
int
int
id
) {
...
}
@PUT
@Path
(
"{id}"
)
@Consumes
(
"application/xml"
)
public
public
void
void
updateCustomer
(
@PathParam
(
"id"
)
int
int
id
,
InputStream is
) {
...
}
}
So, if a client sends
GET /customers/northamerica-db/333
, the JAX-RS provider will
first match the expression on the method
CustomerDatabaseResource.getDatabase()
. It
will then match and process the remaining part of the request with the method
CustomerRe-
source.getCustomer()
.
Besides the added constructor, another difference in the
CustomerResource
class from pre-
vious examples is that it is no longer annotated with
@Path
. It is no longer a root resource in
our system; it is a subresource and must not be registered with the JAX-RS runtime within an
Application
class.
Full Dynamic Dispatching
While our previous example does illustrate the concept of subresource locators, it does not
show their full dynamic nature. The
CustomerDatabaseResource.getDatabase()
method
can return any instance of any class. At runtime, the JAX-RS provider will introspect this in-
stance's class for resource methods that can handle the request.