+1
Disrupting URI Opacity is going to be a really poor statement by this EG,
regardless of how complicated it makes applications. Surely we can find a
way to allow safe methods only (GET, HEAD, etc.)? This is a somewhat
reasonable compromise over breaking URI opacity completely.
Dhanji.
On Wed, Jul 9, 2008 at 6:21 PM, Jerome Louvel <jerome.louvel_at_noelios.com>
wrote:
>
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
>