Java Reference
In-Depth Information
public String getCustomer(@PathParam("
id
") String id) {
...
}
@GET
@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}
.
