On 5/22/12 1:16 PM, 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.
>>>>>
>>>>
>>>> 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?
REST has nothing to do with Java type system. The same URI may have
different representations. Different representations may require
different Java types. Finally, entity providers aren't always the best
solution to the problem.
>
>> 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.
>
If your resource method has a @Produces("application/xml") how are you
supposed to do add support for Json if you can't change the implementation?
>> Other users might want to separate read and write interfaces into separate classes.
>
> That's ok - entity providers have separate interfaces.
Read - GET
Write - PUT, POST, DELETE
>
>> 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.
>
Hey, maybe SEARCH is an optional feature that requires a shit-load of
extra code. Maybe he wants to offer that feature as a separate library.
To me, this isn't much different than having one EJB class for your
JAX-RS interface and another EJB class for your JAX-WS interface.
>>
>>> 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...
Only a locator requires a backtrack. In our impl, a URI match may give
a list of resource methods that match. Doesn't matter what classes
these resource methods are in. We jsut loop through these matches to see
which resource methods support the HTTP method and the Produces/Consumes.
Hey, I've given you a bunch of different reasons why I might want to
ahve multiple classes map to the same URI. Do what you will, but please
don't add a TCK test to enforce it if you decide to keep this restriction.
BTW, is this illegal too?
@Path("/foo/{blah :.*}")
public class A {}
@Path("/foo/bar")
public class B {}
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com