On Apr 26, 2007, at 5:00 PM, Jerome Louvel wrote:
>
> Hi Stefan,
>
> As serving files from directories on the file systems is not really
> in our
> scope,
I don't recall suggesting it was ...
> I think that when users need to specify a special media type that
> they want to get, they have two options:
>
> 1) Adjust their "Accept" header to force the conneg to return a
> specific
> representation
I agree this is the clean way ...
> 2) Rely on a query parameter like "media=application/xml"
>
... while this seems to be just as good or bad as the other suggestion.
> Note that the ".xml" extension is more ambiguous than "application/
> xml" or
> "application/blinksale-xml".
>
I agree.
> We could even automate the translation of the "media" parameter
> into an
> "Accept:" header like we do in the Restlet framework:
> http://www.restlet.org/documentation/1.0/api/org/restlet/service/
> TunnelServi
> ce.html
>
Neat, but I'm not entirely sure I would like to go this far. Enabling
people to build their own content negotiation replacement is one
thing, explicitly coding one into the framework is another - i.e. I
think we should enable common workarounds, but not encourage them.
Stefan
> Best regards,
> Jerome
>
>> -----Message d'origine-----
>> De : Stefan Tilkov [mailto:stefan.tilkov_at_innoq.com]
>> Envoyé : jeudi 26 avril 2007 12:12
>> À : dev_at_jsr311.dev.java.net
>> Objet : Content Negotation vs. Extensions
>>
>> I know the "right" way to do return different representations of a
>> resource is via content negotiation. Still, in many cases it's
>> perceived to be easier to use different extensions for
>> different types.
>>
>> E.g. I could do a GET on http://example.org/customers/4711 to
>> get the
>> default representation, say in HTML, and use http://example.org/
>> customers/4711.xml to get an XML representation. Whether this is
>> "good" or "bad" doesn't really matter IMO; it's going to
>> definitely a
>> common approach. How do we address this?
>>
>> Stefan
>> --
>> Stefan Tilkov, http://www.innoq.com/blog/st/
>>
>> ---------------------------------------------------------------------
>> 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
>