I heard this at a talk too, where someone from Microsoft represented the
JSR-311 EG's opinion as preferring the in-noun content-type. I have to say,
I for one disagree with this as a primary conneg system. Not the least
because this disrupts URI opacity.
I agree with Jerome that the convenience ought to be limited to safe methods
(GET, HEAD, etc.), if specified at all.
Dhanji.
On Fri, Jul 4, 2008 at 7:37 PM, Jerome Louvel <jerome.louvel_at_noelios.com>
wrote:
> Hi all,
>
> In section 3.7.1 of the specs, the preprocessing of extensions for
incoming
> URIs is explained. The idea is to simulate content negotiation without
> having to specify actual Accept* HTTP headers. This is nice.
>
> As mentioned in HTTP 1.1 RFC: "The Accept request-header field can be used
> to specify certain media types which are acceptable for the response".
>
> Therefore it seems confusing to use the pre-processing for methods like
> POST, PUT, DELETE as it becomes impossible to act on a specific
> representation (identified as an independent resource).
>
> For example, let's say we have resource "/path/test" which is available in
> two media types, HTML and XML. It is nice to be able to GET
> "/path/test.html" or "/path/test.xml".
>
> But, if you want to delete only the HTML version, DELETE "/path/test.html"
> will actually become DELETE "/path/test" after pre-processing and actually
> delete the "/path/test" resource and ALL its representations.
>
> Therefore, I think the pre-processing should only be limited to safe
methods
> like HEAD, GET and maybe to OPTIONS method as well.
>
> Best regards,
> Jerome Louvel
> http://www.restlet.org