It’s good to hear Rails 1.2 is all about embracing REST. Working with Ajax has helped me really appreciate the benefits of REST, and it all fits in with the Rails mindset quite nicely. Right now, we have URLs like
whereas REST would have it as
and then POST in the details – the nature of the method (“POST”) tells you it’s an update. Alternative we could send in a message with DELETE method if we wanted to delete user 5 instead. (In practice, there will be a slight hack to do this, involving a hidden field, because most browsers can only upload POST and GET).
By piggybacking on the commonly accepted conventions of REST, there will be even more “convention over configuration” embodied in Rails. And even greater division between RESTians and SOAPians. If nothing else, it’s a smart way to attract people who get REST and repel those who push SOAP ;-). (Software Engineering Radio recently quipped SOA is now just a pure acronym (just like KFC, AOL, Ajax) … it’s not simple, object-oriented, or ?accessible.)
Whereupon a new podcast series begins …
As promised, a new series of Ajax pattern podcasts. This is the first of four podcasts on the Ajax programming patterns.
In this 73 minute podcast, we look at the seven patterns of web services as they relate to Ajax clients.
- RPC Service Expose web services as Remote Procedural Calls (RPCs). (Note: In the book and wiki, REST appears before RPC.) (6:55)
- RESTful Service Expose web services according to RESTful principles. (13:25 )
- HTML Response Have the server generate HTML snippets to be displayed in the browser. (44:45)
- Semantic Response Have the server respond with abstract, semantic, data. (49:00)
- Plain-Text Message Pass simple messages between server and browser in plain-text format. (56:05)
- XML Message Pass messages between server and browser in XML format. (57:20)
Thanks for your feedback since last time. Good, bad, or ugly, it’s all welcome – in the comments for this podcast or [email protected]
Breaking it down:
Web Services patterns are about overall browser-server architecture – what kinds of services and what kinds of messages? It’s relevant to the conversation of Jon Tiersen and others about what sort of responses are possible – XML, JS, HTML, JSON. It’s also relevant to another recent conversation, on [http://www.theserverside.com/news/thread.tss?thread_id=35979 Ajax and webservices], as it covers REST and RPC.
Browser-Server Dialogue covers a mixed bag of patterns about XMLHttpRequest handling and what you can do with it, such as loading JS on demand.
DOM Population is about transforming incoming XML into DOM content, e.g. XSLT.
Performance Optimisation covers a variety of performance patterns such as caching and pre-fetching.
Breakout (can you think of a better name) is about going beyond standard Ajax constraints, namely using a server-side mediator to access external domains and introducing a plugin to go where no Ajax app is allowed to go.
Code Generation and Reuse is strongly related to some of the emerging frameworks like Echo2 and SAJAX.
This is all early days, so any feedback on the structure, names, or content will be taken into account and acknowledged too (really!). OK, here’s the lot …
- RESTful Service Expose web services according to RESTful principles.
- RPC Service Expose web services as Remote Procedural Calls (RPCs).
- HTML Response Have the server generate HTML snippets to be displayed in the browser.
- Semantic Response Have the server respond with abstract, semantic, data.
- Plain-Text Message Pass simple messages between server and browser in plain-text format.
- XML Message Pass messages between server and browser in XML format.
- Call Tracking Accommodate busy user behaviour by allocating a new XMLHtpRequest object for each request. See Richard Schwartz’s blog entry (http://smokey.rhs.com/web/blog/poweroftheschwartz.nsf/d6plinks/RSCZ-6CEQAR).Note: Pending some rewrite to take into account request-locking etc.
- Distributed Events Keep objects synchronised with an event mechanism.
- Fat Client Create a rich, browser-based, client by performing remote calls only when there is no way to achieve the same effect in the browser.
- Browser-Side Cache Maintain a local cache of information.
- Guesstimate Instead of grabbing real data from the server, make a guesstimate that’s good enough for most user’s needs.
- Multi-Stage Download Quickly download the page structure with a standard request, then populate it with further requests.
- Predictive Fetch Anticipate likely user actions and pre-load the required data.
- Cross-Domain Mediator Allow the browser to communicate with other domains by server-based mediation.
- Richer Plugin Make your application “more Ajax than Ajax” with a Richer Plugin.
Code Generation and Reuse
- Ajax Stub Use an “Ajax Stub” framework which allows browser scripts to directly invoke server-side operations, without having to worry about the details of XMLHttpRequest and HTTP transfer.
- Cross-Browser Component Create cross-browser components, allowing programmers to reuse them without regard for browser compatibility.
Aside I was interviewed yesterday for a Japanese magazine about how I’m using the wiki. So maybe some people will be interested to know that I always write the patterns offline because I am more creative in Vim and also to avoid textarea hell. (So much for Writely, will anyone create Vimly, there’s gotta be more money it than cloning MS-Word online :-D). I also use the Mozex or ViewSourceWith extensions to make partial edits using Vim.
This time, I decided not to upload once or twice at a time; but instead all 18 at once.
There’s serious overhead of introducing each new pattern to the wiki (from Vim, the sequence is: 2mins spell-check, 5-10mins markup massaging, 2 mins fixing the link and description on the homepage; sometimes exacerbated by server lag.) Uploading all at once at least allowed me to focus fully on the task and also made some aspects more efficient, particularly updating the homepage.)