Experts,
in a discussion on the Jersey user group someone claimed that the behaviour
of Jersey is different from CXF and RestEasy. As that would imply both, an
inaccuracy of the TCK (it does not detect the deviation) and a violation of
the specification in CXF and RestEasy (as Jersey is the RI, hence
axiomatically cannot be wrong), we should quickly clarify the truth in that
claim.
The case is recorded in Jersey's issue tracker including source code
(
https://java.net/jira/browse/JERSEY-2942) and is simple to explain:
Given a resource has two methods, annotated as @GET @Path(/<PathParam>) and
@DELETE @Path(/<RegEx>)
When a client invokes GET <RootURI>/<PathParam> upon that resource
Then the result is 405 Method Not Allowed
While this looks pretty odd to the average Joe (as there is a perfect match
of GET and <PathParam>), it was claimed that this is compliant to the
specification (since regex have higher priority than literals, and methods
are matched after URIs).
It was reported that CXF and RestEasy return 200 OK instead, while the RI
does return 405 Method Not Allowed.
Certainly an application MUST return the same status code on ANY JAX-RS
compliant implementations, so we should clarify ASAP the following
questions:
(1) @SpecLeads: Is the use case described above (regex beats literals)
really compliant to the JAX-RS specification, and how to explain to the
average Joe the reasonability of ignoring the apparently perfect match?
(2) @SpecLeads: Is there a bug in the TCK so it does not detect the
deviation of CXF and RestEasy?
(3) @Vendors: Can you please check your implementations whether they really
violate the spec? Do you have plans to fix it?
I think we all have a vital interest in clarifying it, as a standard makes
only sense when it is reasonable and commonly accepted, so I would be glad
if you could answer the above points rather soon. :-)
Thanks
-Markus