dev@jsr311.java.net

Re: Proposal for rework of spi package (was Re: "Dual dispatch")

From: Stefan Tilkov <stefan.tilkov_at_innoq.com>
Date: Wed, 25 Apr 2007 23:15:08 +0200

On Apr 25, 2007, at 10:49 PM, Marc Hadley wrote:

> On Apr 25, 2007, at 4:30 PM, Stefan Tilkov wrote:
>
>>>
>>> @UriTemplate("/things/{thing_id}")
>>> public class ThingResource {
>>>
>>> public Thing(@UriParam("thing_id") String id) {...}
>>>
>>> @HttpMethod
>>> Thing get() {...}
>>
>> I think this should still be
>>
>> @HttpMethod @ProduceMime("application/thing")
>> Thing get() {...}
>>
>> because in this class, I may want to return application/thing
>> content, and in another class (or even another method) I might
>> want to use a different content type.
>>
> I think that would make sense for something generic like a String
> return type where the method itself is essentially doing the
> serialization but suppose Thing is a simple Java bean, in that case
> there's no need to have two different methods that return an
> instance of Thing for different media types since one method will do.
>
> I still think it makes sense to support @ProduceMime on the method
> but in some cases I think it could be left out and the runtime can
> still do conneg based on the TypeStreamingProviders.

I agree; the default behavior should be as you suggested (based on
content negotiation), but overridable for cases where this is not
sufficient.

Stefan

>
>>>
>>> One downside I see is that this approach splits the metadata
>>> between two classes - you can't tell just by looking at the
>>> ThingResource class what media types are supported since that
>>> information is contained in the set of TypeStreamingProviders.
>>
>> This problem would disappear with the suggestion above.
>>
> True.
>
> Marc.
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>