Lars Trieloff's Collaboration Weblog

If you are following dev.day.com you have probably seen it already: I will speak next Wednesday at Jazoon conference in Zürich about REST, AJAX and WebForms 2.0. If you are interested in building interactive and standards-compliant web sites and web applications, I would be happy to meet you there.

Btw. I originally planned to call this post "Ten reasons why you will hate not being in Zürich next week", but I decided one uber-catchy headline per week is enough.

As always, I've uploaded my slides of my REST and AJAX reconciled presentation to slideshare. AJAXWorld is a well-produced conference, with around 50 people in the audience, an interesting discussion emerged.

Just a quick note: I will be speaking at AJAXWorld East Conference and Expo in New York. I will present techniques and frameworks for creating RESTful AJAX applications, among the frameworks discussed will be Sling, of couse. My talk is scheduled for wednesday morning, so if you are there, I would love to meet you.

I had a short e-mail exchange with Peter Svenson yesterday, who has some really interesting ideas on web development, Javascript and frameworks and wanted to introduce Sling to him. Unfortunately the Sling website is a bit terse on "big picture" introductions, so I though I share my introduction with my blog readers.

What is Sling? This is a fairly complex issue, because Sling combines many aspects. The main idea is that Sling is a web framework that uses a JCR container such as Apache Jackrabbit as repository. The interesting part here is JCR, which is a storage API that allows you to store nodes which can have child nodes and properties, so the best way is to imagine a JCR repository as a giant storage tree or as a file system on stereoids, as it supports typing, transactions, versioning, full-text-search, oberservation and so on. The main role of Sling is being a translator between the storage repository and the client application and this means representing the Nodes in the JCR tree (that have a path) as Resources (as in REST) that have a URI. ;:A resource can have different representations, for instance a blog can have the HTML representation (blog.html) and the Atom feed representation (blog.atom). Representations are not limited to the resource type, there could be another HTML representation, for example the archive page (blog.archive.html). Representations of a resource are generated on GET requests and there are two high-level ways to do it: Servlets (the classical, heavy-weight Java way) or Scripts and Templates. Among the script engines currently supported are Rhino (Javascript), Ruby, Velocity and Freemarker. Basically, there is a script file or servlet for each representation (in our example html.js, html.archive.js and atom.js could be imaginable). If you want to create a new resource type, e.g. blog entry, you just have to create a new folder and put the appropriately named scripts into this folder. Secondly, a resource can have different behaviors. Again, behaviours are implemented either via Servlets or Scripts. The default behavior is to create a node when posting content to a collection, replacing a node when sending a PUT to a resource and deleting a node when sending a DELETE request. You are, however able to override this default behavior by placing scripts into the right folder. These scripts could for instance validate comment contents before creating the node. This is basically where server side scripting comes into play.

Microjax is based on a clever default handling of certain requests. This means representing resources as JSON objects on GET request and processing JSON request entities for PUT and POST. Additionally, Sling and Microjax introduce two Javascript-based templating mechanisms. Sling comes with the built-in ESP, server-side templating mechanism that will allow you to mash up HTML with embedded Javascript that will be executed server-side, e.g.

<ul>
<% foreach (child in node.children) {
 %><a href="${child.path}"><%= child.properties.name %></a><%
} %>
</ul>

Microsling extends this pattern by introducing EST, which allows you to write the same script, which will then be transformed by the server into a proper Javascript with lots of document.write(...) expressions that can be executed on the client-side.

To sum it up: Take a look at Sling, it is an interesting way to build content-centric applications.

John Udell reviews RESTful Web Services, an O'Reilly book by Leonard Richardson and Sam Ruby. I buy the book. That's what a review should look like. I do not need to read reviews of books I am not going to read.

There is a new JCP aiming to create a Java (TM) API for RESTful Web Services. The proposal was sumitted by Sun and is supported (among others by) Jérôme Louvel, creator of the RESTlet Java framework.

Interesting Commentary:

Pete Layey:

I hope they don’t screw it up (see JAX-WS).

Marc Hadley: provides a code example of what he thinks the API might look like. Looks good from my point of view

Steve Loughran:

It seems to me the people who have a better idea of what to do are the Cocoon folk and Team Netkernel, not the WS projects. Yet I suspect it will be the latter is the most interested, because clearly REST is winning the battle for hearts and minds, at least outside the enterprise. The trouble is, work on WS too long and you get corrupted, you start thinking of methods and operations, not remote state.

Indeed, as we are building REST applications with Cocoon, adhering to or integrating this API is an interesting point to watch. Stefan Tilkov:

First, we asked why he (Marc Hadley) feels a REST-specific JSR is needed, i.e. why Servlets and JSPs are not enough. We also questioned the spec’s wording about low-level APIs, and how one would go about developing RESTful web apps without a deep understanding of HTTP issues and design patterns. Marc replied that while the current APIs provide broad support for HTTP, they leave a lot of work to the developer that could be automated in a higher level API

Contains lots of other good references and quotes.

Gunnar Peterson: REST security (or lack thereof) and Pete Lacey: RESTful Security. Very well written and interesting discussion of Gunnar Peterson's points.