Theory again ... Content negotiation seems beautiful, although popular user agent support has always been weak. Imagine a set of buttons that manifests on your browser with little icons to let you know when the current page is also available in Word, PDF, RSS, etc ... wouldn't that be cool? Well, we sort of have that with RSS in many browsers, but it doesn't use HTTP content negotiation. How about different languages ... I'd love to know that the Noelios page is available in French as well as English and push a convenient button to switch. But, no, and even if your browser is fortunate enough to have the feature, it's neither obvious nor easy to use.
Plus, there is no easy way in HTTP content negotiation to differentiate between different versions of the same mime-type (e.g. text/html) for different purposes. Mobile version, printer friendly version, etc. If these are the same language and same mime-type, even assuming the magic browser features existed that don't exist, we still wouldn't have the facilities in HTTP to effectively address these functional variations on the same general representation type. So we end up putting different variants behind different URIs, so we can put idiot proof links in an HTML page and say "Click here for printer friendly version." Semantically this is just wrong. We're addressing the same resource (same logical end target) but a different representation -- it should have the same URI. Nevertheless, it's what we have to do in a "Web 1.0" browser based web app. What we did in our GoGoEgo CMS (http://gogoego.googlecode.com) was to canonize URIs of the form [data-resource]/[template] for decorated HTML pages. The last token of the URI is used as a lookup into a registry of decorator templates that can pull on the content of the data resource and make a different representation of it, so your "case 1, /user/1/print" is blessed as The Solution in our CMS. Evidence from our 3 or 4 integrators so far is that this can be used very productively. Restlet doesn't really help us with this aspect; we have this one Filter class called GoGoMagicFilter which centralizes all the abominations necessary to implement this templating, as well as trigger the scripting integration, header manipulations, and other misbehaviors that make the HTML/browser/Web 1.0 world livable. And whenever anyone proposes a change to GoGoMagicFilter, a groan goes up and many palms go to faces. Case 5 is so close, but you're right, it's wrong. If there was ever another swing taken at extending RFC 2616 the only one thing I would want to help design in is a standard request/response header pair that existed to pass application-specific "purpose" information -- that behaved like Accept but with application-defined semantics. Stuff like "Printer view" and "Mobile view" comes up all the time, as do similar themes in pulling feeds (preview length...) and image galleries (size...). Maybe there is room for a new RFC like WebDAV RFC 2518 that canonizes some of this. Then, with capable Web 2.0 intelligent clients, I would have a vocabulary for making these functional variants appear under the same URI as I do with other language or mime-type based variants. Anyway, that's just wishful thinking for now ... I have embraced "case 1" and, as the country song goes, that's my story and I'm stickin' to it. - R On Sat, Jun 20, 2009 at 8:22 PM, William Pietri <[email protected]> wrote: > Rob Heittman wrote: > > I find that I've had a hard time implementing complete template-based, > page-based UIs entirely on the server without making a mess. I think > this is because I'm just conflating too many UI concerns in one layer. > > > I've had that feeling recently, too. > > Would people be willing to share examples of how they've done this with > Restlet? For example, the other day we needed to create a print view of one > of our entities. Sticking with the user example, these options occurred to > us, in rough order of preference: > > > 1. /user/1/print > 2. /user/1?view=print > 3. /user/print/1 > 4. /print/user/1 > 5. /user/1 (with a custom media type in the Accept header) > 6. /user/1 (with a POST that requests the print view) > > > The last 4 all strike me as various flavors of wrong. I'm ok with the first > two, but neither seems great to me, in that the URLs suggest different > resources, while we think of the print view as a different representation of > the same resource. > > Since none of the folks on my team feel like we fully get what a RESTful > web app looks like, I'd love to hear how more experienced people do it. > > William > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2363870
