On Sep 20, 2007, at 4:15 PM, 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.
This feels the best to me; it's "content negotiation via uri-basename-
extension" in your face, as it probably should be. The other options
are too flexible. I like to err on the side of constraints these
days, just to make life easier for the 90% solution.
> Alternatively we could go further and have the runtime do the kind
> of request rewriting discussed in (i) so that:
>
> GET /foo.xml
> Accept: */*
>
> is internally treated as if it were:
>
> GET /foo
> Accept: application/xml
One of the worries I have about extension-based content negotiation
is dealing with 'related links' in the content coming out of those.
For instance, if you really wanted to return a link to a resource
"bar" in the content of foo.xml, are you going to return the link as
"bar", or "bar.xml"? I'm thinking you want to return "bar.xml".
which will require the processing of "/foo" to understand that's how
it wants it's links written. And of course you want "foo.json" to
return links as "bar.json".
Tough problem.
Patrick Mueller
http://muellerware.org/