Hi all,
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.
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