On Jan 8, 2008, at 12:15 PM, Bill Burke wrote:
>> 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.
>
Yes, that's true.
> 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.
>
Can you say a little more about why MBR/MBW isn't suitable. Is there
something we could do to improve those interfaces that would make them
workable for you ? Can you describe the use-case in more detail ?
> I just don't see what the big deal is of supporting multiple
> resources/different media types, same path.
>
I guess it just makes the matching algorithm a bit more complex.
Thanks,
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.