Java Reference
In-Depth Information
public String getCustomer(@PathParam(" id ") String id) {
@Path(" { id : .+} / address ")
public String getAddress(@PathParam(" id " ) String id ) {
We've changed getCustomer() 's @Path expression to {id : .+} . The .+ is a regular ex-
pression that will match any stream of characters after /customers . So, the GET /custom-
ers/bill/burke request would be routed to getCustomer() .
The getAddress() method has a more specific expression. It will map any stream of charac-
ters after /customers that ends with /address . So, the GET /customers/bill/burke/ad-
dress request would be routed to the getAddress() method.
Precedence rules
You may have noticed that, together, the @Path expressions for getCustomer() and getAd-
dress() are ambiguous. A GET /customers/bill/burke/address request could match
either getCustomer() or getAddress() , depending on which expression was matched first
by the JAX-RS provider. The JAX-RS specification has defined strict sorting and precedence
rules for matching URI expressions and is based on a most specific match wins algorithm.
The JAX-RS provider gathers up the set of deployed URI expressions and sorts them based
on the following logic:
1. The primary key of the sort is the number of literal characters in the full URI match-
ing pattern. The sort is in descending order. In our ambiguous example, getCus-
tomer() 's pattern has 11 literal characters: /customers/ . The getAddress() meth-
od's pattern has 18 literal characters: /customers/ plus address . Therefore, the
JAX-RS provider will try to match getAddress() 's pattern before getCustomer() .
2. The secondary key of the sort is the number of template expressions embedded within
the pattern—that is, {id} or {id : .+} . This sort is in descending order.
3. The tertiary key of the sort is the number of nondefault template expressions. A de-
fault template expression is one that does not define a regular expression—that is,
{id} .
Search WWH ::

Custom Search