Java Reference
In-Depth Information
Here's where the weirdness comes in. Let's say you have the HTTP request
OPTIONS /a/b
.
If you expect that the
Resource2.options()
method would be invoked, you would be
wrong! You would actually get a 405, “Method Not Allowed,” error response from the serv-
er. This is because the initial part of the request path,
/a
, matches the
Resource1
class best,
so
Resource1
is used to resolve the rest of the HTTP request. If we change
Resource2
as
follows, the request would be processed by the
options()
method:
@Path
(
"/a"
)
public
public class
class
Resource2
Resource2
{
@OPTIONS
@Path
(
"b"
)
public
public
Response
options
() {}
}
If the
@Path
expressions are the same between two different JAX-RS classes, then they both
are used for request matching.
There are also similar ambiguities in subresource locator matching. Take these classes, for
example:
@Path
(
"/a"
)
public
public class
class
Foo
Foo
{
@GET
@Path
(
"b"
)
public
public
String
get
() {...}
@Path
(
"{id}"
)
public
public
Locator
locator
() {
return
return new
new
Locator
(); }
}
public
public class
class
Locator
Locator
{
@PUT
public
public
void
void
put
() {...}
}
If we did a
PUT /a/b
request, you would also get a 405 error response. The specification al-
gorithm states that if there is at least one other resource method whose
@Path
expression
matches, then no subresource locator will be traversed to match the request.
In most applications, you will not encounter these maching issues, but it's good to know
about them just in case you do. I tried to get these problems fixed in the JAX-RS 2.0 spec,
but a few JSR members thought that this would break backward compatibility.
