On May 22, 2012, at 3:06 PM, Bill Burke wrote:
>
>
> On 5/22/12 5:28 AM, Marek Potociar wrote:
>>
>> On May 21, 2012, at 10:35 PM, Bill Burke wrote:
>>
>>> I can see users wanting to add support for different formats in different resource classes. i.e.
>>>
>>> @Path("/root")
>>> @Produces("application/xml")
>>> public class MyRootXmlSupport {}
>>>
>>> @Path("/root")
>>> @Produces("application/json")
>>> public class MyJsonSupport {}
>>>
>>
>> One of the main design concepts behind JAX-RS is that it should produce a representation independent model. The above use case just seems artificial to me and goes against the intended best practices.
>>
>
> Whose best practices are you talking about? Its definitely not a bad practice, especially if there any media type formatting specific logic. Especially if your JAX-RS services are just a face over some EJB you are delegating to.
JAX-RS best practices (see spec section 1.2 Goals - "Format independence") which are based on REST. Also a single URI should represent a single resource. The example above would be better modeled in JAX-RS as a single resource class and multiple entity providers. That plays well with OOD as well as JAX-RS/REST principles. The above is just poor design and a good example of why I would not want the spec to promote it as a standard.
>
>>>
>>> I can also see the following:
>>>
>>> @Path("/{options : .*}")
>>> public class HandleOptionsGenerically
>>> {
>>> @OPTIONS
>>> public Response handleOptions() {...}
>>> }
>>>
>>
>> That one requires IMO changing the matching algorithm to support full back-tracking, which would make the matching very inefficient. To put it clearly, I am not going to support any change request that would require introduction of back-tracking into the matching algorithm.
>>
>
> Well, in resteasy we do a recursive depth first search on a tree of mapped resource methods. Locators are always matched after static and expression-based paths are evaluated. We don't backtrack on locators.
It is your prerogative to implement the matching algorithm in any way you want as long as the result complies with the spec and you pass TCK tests. Important however is that the spec algorithm does not force you to use DFS with back tracking to implement the resource matching (in fact it is trying to avoid it) and I hope you don't want to force other impls. to follow your path.
>>>
>>> BTW, I didn't even know this restriction existed and is something we already do by default in resteasy. I don't see why it is a big deal to support/allow.
>>
>> See my reasoning above.
>>
>
> I think your reasoning is flawed. I don't see how 2 classes with the same @Path expression is any different from 2 methods with the same @Path expression. Matching should be based on resource methods, not resource class except for the case of a sub-locator.
Not sure we are on the same page. I am not saying that implementation of the first use case - multiple resource classes on a same resource path - (which matches the subject of the Jira issue) would require back-tracking or that it cannot be done. In fact we already can support it in Jersey without any backtracking. I am however saying that it has a negative impact on code readability and maintenance, which makes it a bad practice and as such should not be promoted by the spec as a standard. If any implementation decides to support it, I'm fine with that. If we see that many users use the feature and that it becomes an essential part of many RESTful applications, I would revisit my position. But so far we have not heard any user complaints about the feature missing in Jersey.
Now as for the second use case with OPTIONS support - that one would most certainly require use of back-tracking. Here I can only repeat that I am not going to support any change request that would require introduction of back-tracking into the matching algorithm.
> BTW, if you guys ever add a TCK test for this, I think there would be at least a few pissed off users.
We're adding lots of TCK tests - we're currently at ~ 910 (compared to ~ 280 in JAX-RS 1.x). Still, if you have any particular suggestions for a new test addition, please feel free to file a JIRA issue.
Marek
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com