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

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

From: Bill Burke <bburke_at_redhat.com>
Date: Tue, 22 May 2012 12:49:49 -0400

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.
>>>
>>
>> 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'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.

There's also the possibility of wanting to add support for a different
media type to an existing library.

Other users might want to separate read and write interfaces into
separate classes.

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.

> 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".

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