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.