Den 8. juli. 2008 kl. 17.39 skrev Matt Brozowski:
> On Tue, Jul 8, 2008 at 4:14 AM, Marc Hadley <Marc.Hadley_at_sun.com>
> wrote:
>> 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 ?
I use it (if not cleanly integrated yet). As I promote html
representations for browsers (see below), it's a nice way to allow
browsers to display the json/xml representation of the resource.
I don't really see why DELETE on 'resource.html' should be treated any
differently than DELETE on 'resource'. When enabling this feature you
have explicitly said that you want *the same* resource to be avaliable
on both uris, they just have different implementations of conneg? If
you don't want that, why enable the feature?
> I think removing the feature would be a mistake. I've done a recent
> review of the most popular browsers and they all say the prefer xml
> to text/html. I have been working on a sample application that used
> the same jax-rs resources to server both a webapp and a web
> service. The webapp is served via HTML and the web service via
> XML. However without relying on the extensions there would be no
> way to reliably serve html to the browsers (since they all state
> they prefer xml over html)
I have worked around this by preprocessing the accept header (in a
servlet filter) to promote text/html if the client says it supports
it. It works for my use case, and seems like a valid way for the
server to implement conneg. If the client really don't want html, it
simply shouldn't accept it.
Jo