Hi Jerome,
you are right: It is a hack. But the browser limitations are the
reality. So we need a way to handle it. Otherwise everyone implements
its own hack and the compatibiliy is away.
But I agree with you, that the file extensions are not nice for unsafe
methods.
best regards
Stephan
Jerome Louvel schrieb:
> 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