Marc Hadley wrote:
> On Jan 8, 2008, at 10:52 AM, Bill Burke wrote:
>>
>> I extremely disagree. Same Path, different resources, different
>> MediaTypes is definately needed. You mean to tell me that I'm going
>> to bloat each resource class to support all the media formats I want?
>> This just isn't good design guys...
>>
>> I've already run into this issue in the prototype application I'm
>> writing which is why I modified my JSR-311 implementation to support
>> same path, different resources/different media types.
>>
> I think it depends on where you intend to put the
> serialization/deserialization logic. Using MessageBodyReaders and
> MessageBodyWriters you can have the same datatype being serialized
> to/from a variety of formats while only using a single resource class.
> E.g.:
>
> @Path("foo")
> public class FooResource {
>
> @GET
> FooData getData() {...}
> }
>
> FooData is the Java bean you work with in your code and is the only type
> understood directly by the resource. You can then have
> MessageBodyWriters for a variety or formats without duplicating the
> resource logic in additional resource classes.
>
You have a good point, but that doesn't mean this way of designing
resources would cause resource logic duplication.
Inheritance/delegation can take care of that.
Still, in my particular use case, MessageBodyReaders/Writers aren't a
good enough abstraction for what I'm doing as I'm not working with an
object model, but just raw metadata.
I just don't see what the big deal is of supporting multiple
resources/different media types, same path.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com