Farrukh Najmi wrote:
> 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
>
Another common way is to do the following (like Ruby on Rails):
GET /search/FindPlacemark.atom?name=mercy&description=hospital
GET /search/FindPlacemark.ebrim?name=mercy&description=hospital
GET /search/FindPlacemark.html?name=mercy&description=hospital
We are planning to support such 'distinct' URIs, like above, using a
suffix mechanism as well as the platonic (canonical one):
GET /search/FindPlacemark?name=mercy&description=hospital
that works using the Accept header. In general the whole thing will
blend in with @ProduceMime and the developer should just declare such
behavior using some value on the @Path annotation.
I prefer using a suffix mechanism because it keeps things neater and
scoped to the URI path, hence it can work better with caches that ignore
query parameters.
>
>
>>
>>
>>> 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.
>
I meant it specifically in terms of the resources *you* are defining and
not in general :-) first ask what the URIs are and how they map to Java
classes that are resources, then ask what HTTP methods are supported on
the resources, then ask what media type those methods consume and
produce. I find those types of questions in that order are very helpful
when designing a RESTful Web application.
>>
>> 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?
Perhaps, it depends whether the service needs to be fully dynamic w.r.t.
to media because the *client* decides what the media is, or the list is
relatively static and grows as more media is explicitly supported by the
service.
For example an image conversion service would let the client decide what
image media to convert from and to and the service would reject a
request if the image media is not supported. On the other hand if you
develop a service then want to add atom support you would more likely
explicitly more methods to support this.
> Seems a little hairy.
>
Perhaps, if used for the wrong reason.
> 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.
>
My guess is that fits better your design.
>>
>>
>> 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.
>
I will keep you posted!
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109