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

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Wed, 25 Apr 2007 16:49:04 -0400

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.

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


Marc Hadley <marc.hadley at>
CTO Office, Sun Microsystems.