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.