On Sep 27, 2007, at 10:56 AM, Marc Hadley wrote:
>
> Off the top of my head we could support something like:
>
> @UriTemplate("{id}")
> @HttpMethod
> @ProduceMime("application/xml")
> SomeItem getItem(@UriParam("id") String itemId)
>
> with a configuration file:
>
> <application xmlns="...">
> <extensions>
> <extension value="xml" mediaType="application/xml"/>
> <extension value="json" mediaType="application/json"/>
> ...
> </extensions>
> ...
> </application>
>
> such that
>
> GET /1.xml
> Accept: */*
>
> is treated identically to
>
> GET /1
> Accept: application/xml
>
> Question: should an extension override an accept or enhance it,
> e.g. should
>
> GET /foo.json
> Accept: application/xml
>
> cause an error (assuming .json was mapped to application/json) or
> should it effectively add application/json to the Accept value ?
>
Answering my own question, I think the only workable approaches are
to make it an error condition if the extension and accept don't match
or have the extensions *override* the accept. Consider the following:
@UriTemplate("foo")
public class Foo {
@ProduceMime("application/xml")
@HttpMethod(GET)
Source getXml() {...}
@ProduceMime("application/json")
@HttpMethod(GET)
Source getJson() {...}
}
If the extension adds to the accept then:
GET /foo.json
Accept: application/xml
would be treated like:
GET /foo.json
Accept: application/xml, application/json
and the runtime would still need to decide which of the acceptable
formats to return. If it picked XML then the response would be
counter intuitive.
If instead the extension overrides the accept then the request would
be treated like
GET /foo.json
Accept: application/json
and would proceed as expected.
Following the "be liberal in what you accept and strict in what you
produce" approach I think we should go with the override rather than
making it an error condition but I'm open to counter arguments.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.