dev@jsr311.java.net

Re: JSR311: Limit extensions pre-processing

From: Stephan Koops <Stephan.Koops_at_web.de>
Date: Tue, 08 Jul 2008 10:05:52 +0200

Hi,

I think the URI pre processing for content negotiation is a very useful
feature and we should have something for this available.
For GET the current approach with the extensions seems very good to me.
For POST, PUT, DELETE etc. I agree with Jerome, that the current
approach is not really good. We could use query parameters for the
content negotiation, which should be removed from the URI as the
extensions. For this we should give developers a possibility to define
own safe methods, e.g. for WebDAV.

best regards
   Stephan

Jerome Louvel schrieb:
> Hi all,
>
> I understand that such a change would complicate the API but my bigger
> concern is that we break the HTTP semantics (URI opacity) here. Deleting a
> representation (via its specific URI) shouldn't delete the whole resource.
>
> If we can't cleanly adjust the API to take this into account, I would prefer
> removing the pre-processing feature itself.
>
> Best regards,
> Jerome
>
>
> -----Message d'origine-----
> De : Bill Burke [mailto:bburke_at_redhat.com]
> Envoyé : lundi 7 juillet 2008 16:09
> À : dev_at_jsr311.dev.java.net
> Objet : Re: JSR311: Limit extensions pre-processing
>
> 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