Jersey is correct in that example - a template var with a regex wins
over a basic template var.
The spec clearly states that an expression with more literal chars wins.
So I guess a regex expression can only win if, besides the rex-ex
expression itself, a given path has more literal chars, say, abc[d|e]
would win over abc - I think this can only happen when choosing between
multiple matching root resources.
Or it can win in that Jersey JIRA issue - a number of literal chars
beyond the regex is equal but the regex method wins because a template
var is more specific. I'll double check with CXF - I doubt it works diff
in CXF
Sergey
On 11/10/15 08:28, 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
>