jsr370-experts@jax-rs-spec.java.net

Re: _at_Path with regular expression overrides other _at_Path's with the same URI

From: Bill Burke <bburke_at_redhat.com>
Date: Mon, 12 Oct 2015 08:52:19 -0400

Both are reg exp. The @Path - reg ex is probably more specific than the
<path param>, so the regex would be picked. Read the spec, you have to
count characters in the expressions. path param has none.

On 10/11/2015 3:28 AM, Markus KARG wrote:
> 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 **_at_GET
> @Path(//<PathParam>/) and **_at_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
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com