users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Re: Re: Re: Re: Re: Allowing two resources to be mapped to the same URI

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Wed, 23 May 2012 18:18:48 +0200

On May 23, 2012, at 5:08 PM, Sergey Beryozkin wrote:

> On 23/05/12 15:40, Marek Potociar wrote:
>>
>> On May 23, 2012, at 2:06 PM, Sergey Beryozkin wrote:
>>
>>> On 23/05/12 12:15, Marek Potociar wrote:
>>>>
>>>> On May 22, 2012, at 11:01 PM, Sergey Beryozkin wrote:
>>>>
>>>>> Just one comment,
>>>>> On 22/05/12 18:16, Marek Potociar wrote:
>>>>>>
>>>>>> On May 22, 2012, at 6:49 PM, Bill Burke wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 5/22/12 11:52 AM, Marek Potociar wrote:
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>>>
>>>>>
>>>>> IMHO there's nothing wrong in having a dedicated resource handler, root handler, whatever one can call it, allocated to managing a specific resource representation. So MyRootXmlSupport& MyRootJsonSupport are looking OK.
>>>>>
>>>>> However, I haven't seen a big demand for multiple root resources sharing exactly the same path. This can actually be easily resolved without any back tracking, but I reckon that a combination of root resources and sub resource locators can often be sufficient to get a similar 'setup'.
>>>>>
>>>>> Perhaps if there's some compelling reason to support such a case then may be it can be reviewed
>>>>
>>>> The use case of providing optional support for additional resource methods (e.g. SEARCH) that may be e.g. too memory-consuming for minimalistic application deployments is what convinced me to support the construct in the end.
>>>
>>>
>>> Sounds interesting. Do you have some initial ideas on how the matching algorithm may need to be changed ?
>>
>> Santiago took AI to look at that. Seems like the wording of the 3.7.2 may need to change quite a bit, but the algorithm should remain essentially the same, except you may need to do a method selection based on all methods from all resource classes that declare the same matching URI template that matched the request URI. Sounds like a bit of work...
>
> The question is where does it have to stop so to say. Each root resource may have few matching subresource locators.

Not sure I follow. We are only talking about values of @Path annotations placed directly on the root resource classes. Where do the sub-resource locators come to the picture?

> I hope it can be a minimalistic and 'cheap' to implement and support change.

Should be - the only difference is that you may need to "group" all root resource classes with the same URI templates (ideally at deploy-time) and then once you match the template you would process all the methods of the all classes in the group as opposed to processing all the methods of just a single class as it is currently stated in the algorithm.

>
> Example, if we have two matching methods returning sub resource locators, then the more specific one wins. In fact the same is true for the root resource candidates.

That should be preserved.

>
> The only case is what to do when the final matching group is equal between the selected candidates. I propose that in this case we go on via every candidate and find the first matching method (HTTP verb + path + media types), ignoring subresource locators. If we have both candidates with possible method candidates, then both method candidates ate compared next and that is it...Lets try to keep it as simple as possible

Not sure I follow here completely. In any case, I do agree we should try to keep the change as simple as possible. That's why the idea is to change just the root resource selection from a single resource to all resources with the same template. So instead of a list of methods from a single class [C1.m1(), C1.m2(), C1.m3()] You would in the next phase of the matching process a list of methods from potentially multiple classes [C1.m1(), C1.m2(), C1.m3(), C2.m1(), C2.m2(), C3.m1()]. But since the relevant processing meta-data are the same regardless of which class each particular method belongs to, the actual method list processing would essentially remain the unchanged.

Marek

>
> Thanks, Sergey
>
>
>
>>
>> Marek
>>
>>>
>>>
>>> Cheers, Sergey
>>>
>>>
>>>
>>>>
>>>> Marek
>>>>>
>>>>> Sergey
>>>>>
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>
>>>>>>> REST has really nothing to do with Java class design. And your assumptions are completely false that it as bad OOD too.
>>>>>>
>>>>>> I would disagree.
>>>>>>
>>>>>>> I've had plenty of users where their formatting requirements don't fit well with the whole MBR/MBW/JAXBContext/ObjectMapper/ContextResolver pattern and have had to do things more "manually" within a resource method. Also, many times people prefer to use Document + XPath as it gives them a lot of flexibility, rather than JAXB. They would of course use different APIs on the JSON side. It makes perfect sense to separate JSON from XML processing into separate classes in this case.
>>>>>>
>>>>>> Do the resource classes represent the same noun, same data? Do they produce same Java types? If not, why? And why they need to be on the same path? And how RESTful is that?
>>>>>>
>>>>>>> There's also the possibility of wanting to add support for a different media type to an existing library.
>>>>>>
>>>>>> That should be done via entity providers.
>>>>>>
>>>>>>> Other users might want to separate read and write interfaces into separate classes.
>>>>>>
>>>>>> That's ok - entity providers have separate interfaces.
>>>>>>
>>>>>>> In the JIRA case, the users just wants to have a separate class to implement his SEARCH requirements. That works well for his application and its arrogant to call his decisions bad practice or bad design where you have no idea what his code looks like.
>>>>>>
>>>>>> You may call it arrogant, but it is my right to voice my opinions in this forum. With the data that I have about the case I feel that the design smells. Maybe in the user's case after seeing the whole big picture it would not smell (or would smell less), I don't know. But the point is that in general I'm convinced this practice may lead to confusing designs and would actually back-fire in hands of perhaps less skilled users. Since the feature does not bring anything that could not be worked around and it is not a mainstream case, I don't see a sound reason for adding it to the spec.
>>>>>>
>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>
>>>>>>> Spec language of "the matching algorithm does not require backtracking and thus applications may be required to provide less complex or more specific mappings to get around URI matching ambiguities."
>>>>>>>
>>>>>>> Is much better than the restriction of "You can only have one resource class mapping per URI".
>>>>>>
>>>>>> How does that relate to your options case? That would require back-tracking no matter what...
>>>>>>
>>>>>> Marek
>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Bill Burke
>>>>>>> JBoss, a division of Red Hat
>>>>>>> http://bill.burkecentral.com
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sergey Beryozkin
>>>>>
>>>>> Talend Community Coders
>>>>> http://coders.talend.com/
>>>>>
>>>>> Blog: http://sberyozkin.blogspot.com
>>>>
>>>
>>>
>>