Marc Hadley wrote:
> 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...
>
Right. There would be no need to utilize the @UriExtension parameter for
such cases if it is agreed that there is a single extension that
corresponds to the media:
@UriTemplate(value="{id}" extensions=true)
public class SomeResource {
// works for {id} when "application/json" is acceptable
// and {id}.xml and overrides Accept, internally "xml" is mapped
// to a client that accepts "application/xml"
@HttpMethod
@ProduceMime("application/xml")
String getAsXml() {
...
}
// works for {id} when "application/json" is acceptable
// and {id}.json and overrides Accept, internally "json" is mapped
// to a client that accepts "application/json"
@HttpMethod
@ProduceMime("application/json")
String getAsJson(@UriExtension String exts[]) {
...
}
}
Because the extension details are not specified in the URI template it
is really tricky when dealing with multiple extensions to work out what
extension corresponds to what HTTP item.
It would be much easier if things were more explicit:
@UriTemplate("{id}", extensions={"{accept}", "{accept-lang}?"})
Which means there are three templates:
{id}
{id}.{accept}
{id}.{accept}.{accept-lang}
In this case the ordering and mappings are very clear.
Ideally i would like to extend the URI template syntax but to express
this in one string gets rather complicated, e.g.: \(\) = optional group
{id}\(.{accept}\(.{accept-lang}\)\)
Paul.
> Marc.
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109