Although I've found this feature kind of awkward to begin with (not sure
I'd ever use it), I agree with Marc.
Marc Hadley wrote:
> On Jul 4, 2008, at 5:50 AM, Dhanji R. Prasanna wrote:
>
>> 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.
>>
> Hmm, the problem is that then you need to have different paths for
> different methods. E.g.
>
> @Path("foo/{id}")
> public class FooResource {
>
> @GET
> Foo getFoo() {...}
>
> @DELETE
> Response deleteFoo() {...}
> }
>
> Assuming you've configured a mapping from .html to text/html then
>
> GET foo/10
> GET foo/10.html
> DELETE foo/10
> DELETE foo/10.html
>
> All get handled by FooResource since the .html is stripped by the
> preprocessing prior to matching.
>
> Now if the preprocessing only applies to GET, HEAD etc then the DELETE
> requests will no longer match the path template for FooResource and
> you'll have to add another class with an @Path("Foo/{id}.{format}") to
> handle the DELETE.
>
> UriInfo.getConnegExtension allows an application to determine whether
> the request was for /foo/10 or foo/10.html and the application can do
> the right thing based on that.
>
> I think limiting extensions in the way suggested would just complicate
> the developers life.
>
> Marc.
>
>>
>> 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
>>
>
> ---
> 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
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com