Java Reference
In-Depth Information
public
public
void
void
updateCustomer
(
@PathParam
(
"first"
)
String firstName
,
@PathParam
(
"last"
)
String lastName
,
InputStream is
) {
...
}
}
Customer lookup requests routed to
europe
would match the
/customers/{database}-db/
{id}
URI pattern defined in
CustomerResource
. Requests routed to
northamerica
would
match the
/customers/{database}-db/{first}-{last}
URI pattern defined in
FirstLastCustomerResource
. This type of pattern gives you a lot of freedom to dispatch
your own requests.
Gotchas in Request Matching
There are some fine print details about the URI request matching algorithm that I must go
over, as there may be cases where you'd expect a request to match and it doesn't. First of all,
the specification requires that potential JAX-RS class matches are filtered first based on the
root
@Path
annotation. Consider the following two classes:
@Path
(
"/a"
)
public
public class
class
Resource1
Resource1
{
@GET
@Path
(
"/b"
)
public
public
Response
get
() {}
}
@Path
(
"/{any : .*}"
)
public
public class
class
Resource2
Resource2
{
@GET
public
public
Response
get
() {}
@OPTIONS
public
public
Response
options
() {}
}
If we have an HTTP request
GET /a/b
, the matching algorithm will first find the best class
that matches before finishing the full dispatch. In this case, class
Resource1
is chosen be-
cause its
@Path("/a")
annotation best matches the initial part of the request URI. The
matching algorithm then tries to match the remainder of the URI based on expressions con-
tained in the
Resource1
class.
