Chris, Currently, the logic to select the best representation based on client preferences is fully reusable, see ClientData.getBestVariant() method in beta 18. However, the usage of extensions to (optionally) specify the desired media type or language or encoding is only available in the DirectoryHandler/ContextClient (mapping files to resources and representations).
It sounds like a useful thing to have in the TunnelFilter too and potentially other places. This filter could then enable the support URIs like: /book/123 and /book/123.json without additional code. We could even let people specify multiple preferences and types of preference as the extensions are guaranteed to be unique: /book/123.fr.xml.zip I've entered a new request for this: http://restlet.tigris.org/issues/show_bug.cgi?id=147 In addition, after stepping back a little, it seems that your resource design is not precise enough. It makes sense to allow negotiation between "JSON", "XML" and maybe "text" media types, but "image" seems like a good candidate for being a different resource. As URIs are cheap, why not simply specify another resource for it? Like "/book/123/cover". As a client, it shouldn't matter too much which representation you are getting from a server as long as you accept it as the representations should be semantically equivalent. Clearly, getting the image of the cover is quite different from getting its description as structured text... But there will always be cases where you need a precise representation (cf our discussion on resource vs representation) to allow the specification of extensions at the end of URIs is a cool idea. Best regards, Jerome > -----Message d'origine----- > De : Chris Winters [mailto:[EMAIL PROTECTED] > Envoyé : mardi 8 août 2006 21:29 > À : [email protected] > Objet : Re: Accept header vs. explicit (was: RE: > representations + caching (ETags, etc.)) > > John D. Mitchell wrote: > > FWIW, I don't find relying on the accept header to be > reliable because > > of these kinds of issues. > > > > Even if you do support the accept header, it seems to be a > good idea > > to also support the explicit specifying of the type in the > link such > > as .xml/.json/etc. An example of this is the Zimbra API, IIRC. > > That's a good idea; but I'm not too worried about lock-in > since I figure > the code is readily available to choose the best variant > based on a file > extension versus the Accept header. That would probably be a useful > tutorial though :-) > > Chris > > -- > Chris Winters ([EMAIL PROTECTED]) > Lead Software Developer > Vocollect Healthcare Systems > > CONFIDENTIAL, PRIVILEGED COMMUNICATION: This e-mail is private and > intended for the addressee(s) only. It may contain privileged and/or > confidential information. If you have received it in error > you are not > authorized to disseminate it in any manner; please delete it and any > copies and reply to the sender that it was misdirected. > > >
