Paul Sandoz wrote:
> Farrukh Najmi wrote:
>>
>> My rest interface needs to return responses conforming to different
>> media types based upon a responseFormat option.
>
> By "responseFormat option" do you mean the client HTTP Accept header?
Similar in concept but the spec uses an option based on the assumption
that support for ACCEPT header is not obvious
and universal. Feel free to comment on this.
Examples are:
GET
/search/FindPlacemark?name=mercy&description=hospital&responseFormat=application/atom+xml
GET
/search/FindPlacemark?name=mercy&description=hospital&responseFormat=application/ebrim+xml
GET
/search/FindPlacemark?name=mercy&description=hospital&responseFormat=text/html
>
>
>> What is the best approach for return type design for methods with GET
>> annotation?
>>
>
> Do different resources support different media types?
Any given resource can support multiple media types.
>
> Are the media types fixed or dynamic or both depending on the content?
The following is ideally what I need....
The media types are extensible for a given deployment but generally the
same set of choices regardless of resource.
The design should allow for new media types to somehow be added. Perhaps
this means using the Response
type as response of my GET methods? Seems a little hairy.
Perhaps at dev time we decide which media types are supported and use
the method below you gave. This will simplify things
a lot. Let me know if I can do the more sophisticated media type support
without too much complexity.
>
>
> If you want to support say Atom and an alternative XML format you can do:
>
> @ProduceMime("application/atom+xml")
> @GET Entry getEntryAsAtom() { ... }
>
> @ProduceMime("application/xml")
> @GET JAXBBean getAsAtom() { ... }
>
> If the most acceptable response (determined from the client HTTP
> Accept header) is "application/atom+xml" then the method
> "getEntryAsAtom" will be invoked.
>
> For the 0.5 Jersey release we will be working on better support for
> programmatic selection for wild card media types. But it is not fully
> implemented yet.
This sounds interesting but the trick will be to keep it simple. Look
forward to learning more over time. Thanks again for the good advice.
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com