On Jul 9, 2008, at 10:21 AM, Jerome Louvel wrote:
>
> I agree with you all that the feature IS useful for GET, HEAD and
> OPTIONS
> methods but don't see the point of allowing it for other methods.
>
> After, checking the latest JAX-RS specs, I wonder why @Path("foo/
> {id}")
> wouldn't match both 'foo/10' and 'foo/10.html'? After all, '.' is
> allowed in
> path segments.
>
It would match, the problem is that then @PathParam("id") would give
either 10 or 10.html so the application would need to tokenize the id
and do its own "content negotiation" based on the presence/absence of
".html". With the current scheme, applications can use @Produces to
select between representation formats regardless of whether conneg is
based on the Accept header or path extension.
You also couldn't use, e.g.
@PathParam("id") int id
to get an integer identifier since the .html would mess with the
conversion and you'd lose the extension so essentially you're back to
String for all args or custom written types that do the tokenization.
Marc.
> Let's say our 'foo/{id}' resources are backed by concrete files. We
> could
> have a 'foo/10.html' file and a 'foo/10.xml' file. If I just want to
> remove
> the XML version because I don't have any more use for it, doing DELETE
> 'foo/10.xml' should just do that. Doing DELETE 'foo/10' should
> delete both
> files. That is actually consistent with GET 'foo/10' which would
> negotiation
> across both files while GET 'foo/10.xml' would go straight to the XML
> variant.
>
> This is more flexible, more consistent with URI opacity and HTTP
> specifications. IMO, the extensions pre-processing is just a
> convenient hack
> to workaround browser limitations (no easy access to Accept HTTP
> headers).
> This hack shouldn't become the standard.
>
> Best regards,
> Jerome
>
> -----Message d'origine-----
> De : Marc.Hadley_at_Sun.COM [mailto:Marc.Hadley_at_Sun.COM]
> Envoyé : mardi 8 juillet 2008 10:14
> À : dev_at_jsr311.dev.java.net
> Objet : Re: JSR311: Limit extensions pre-processing
>
> On Jul 8, 2008, at 9:53 AM, Jerome Louvel wrote:
>>
>> I understand that such a change would complicate the API but my
>> bigger
>> concern is that we break the HTTP semantics (URI opacity) here.
>
> Its not that the API would be more complicated, its that applications
> would be.
>
>
>> Deleting a
>> representation (via its specific URI) shouldn't delete the whole
>> resource.
>>
> As I explained, it doesn't have to, the application can look at the
> extension to determine whether a specific resource or representation
> is the target. This seems the lesser evil compared to requiring two
> resource classes (one for the platonic URI, one for the specific).
>
>
>> If we can't cleanly adjust the API to take this into account, I
>> would prefer
>> removing the pre-processing feature itself.
>>
> Removal of the feature is a possibility, it could be cleanly removed
> without too much impact elsewhere. However I think its a useful
> feature and my preference is to retain it - what do others think ?
>
> Marc.
>
>>
>>
>> -----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
>>>>
>>>
>>> ---
>>> 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
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>>
>
> ---
> 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 unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.