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.
>
True.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.
- application/pkcs7-signature attachment: smime.p7s