On Sep 25, 2007, at 7:05 AM, Paul Sandoz wrote:
> Marc Hadley wrote:
>> (iii) We could consider including adding some convention-driven
>> support to the UriTemplate annotation. E.g.:
>> @UriTemplate(value="{id}" extentions=true)
>> The above could surface a fixed-name URI template variable for any
>> supplied extension so that for "foo.xml" you'd get UriParam("id")
>> ==foo, UriParam("extension")==xml.
>
> I am leaning towards this approach.
>
Rather than a fixed-name URI template variable I think it would make
sense to define a separate annotation since the semantics could
usefully differ from URI template variables. Such a mechanism could
be used to drive more than just content type selection, it could also
drive language and charset selection. E.g.
@UriTemplate(value="{id}" extensions=true)
public class SomeResource {
@HttpMethod
String get(@UriExtensions String exts[]) {
...
}
}
GET /foo.xml => exts={"xml"}
GET /foo.xml.en => exts={"xml","en"}
GET /foo.en.xml => exts={"en","xml"}
GET /foo.en.utf8 => exts={"en","utf8"}
The interaction between the above and the @ProduceMime annotation is
tricky, consider
@UriTemplate(value="{id}" extensions=true)
public class SomeResource {
@HttpMethod
@ProduceMime("application/xml")
String getAsXml(@UriExtension String exts[]) {
...
}
@HttpMethod
@ProduceMime("application/json")
String getAsJson(@UriExtension String exts[]) {
...
}
}
GET /foo.xml, Accept: */* - how does the runtime know which method to
invoke ?
Unless we build in some automated support for mapping a URI extension
(e.g. .xml) to an effective Accept header then we lose the benefit of
@ProduceMime...
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.