Via Seth Gottlieb news that Apache Sling has been officially released. Sling is interesting–I’ve played with it only a bit. You can read more about it on Seth’s post but essentially it is a REST API that sits on top of Apache Jackrabbit. Jackrabbit is the reference implementation of the JCR spec.

I’m not crazy about the JCR API because it is Java-only (yes, I know there are bridges out there). Plus, it doesn’t seem to be rich enough for many types of implementations. For example, Alfresco is a JCR-compliant (Level One) repository, but you don’t see too many people doing JCR-only interactions with Alfresco.

What is interesting to me, though, is the idea that you can abstract repositories at a higher level: the REST API. If we’re all going to talk to our repositories via REST, why not do it in a standard way?

Alfresco introduced a REST framework in 2.1 called “web scripts” (learn more). But Alfresco does not yet have a full-blown “REST API”. Yes, there are a few out-of-the-box REST calls but for the most part, when you interact with Alfresco via REST you are going to roll your own API. On Optaros projects, this has not yet been a huge burden. Quite the opposite, in fact–we’ve been able to develop everything from web script-backed JSR-168 portlets to a streamlined version of the Alfresco web client (soon to be released as an open source project), all on web scripts.

As part of 3.0, Alfresco anticipates rolling out additional out-of-the-box URLs to more fully establish the REST API. The new 3.0 web clients are based almost entirely on REST so they might as well build a REST API that we can all use.

When I look at Apache Sling, I’m thinking, why don’t we agree on a standard REST API for working with content repositories. Then, we could write a front-end once and theoretically use it with multiple back-end repositories. If someone then wants to use a JCR-compliant repository behind the scenes, then that’s cool, but it isn’t a requirement.

Obviously, there is a granularity challenge here. If the API is too granular the front-end ends up making too many calls. If you are aggregating multiple calls from within an intermediate application and then returning the result to the front-end (rather than making a bunch of AJAX calls initiated from the browser client), that’s not as much of an issue. If the API is too coarse, it is too hard to reuse across many different types of front-end applications.

Still, if we agree that REST is the preferred interaction model in the “content as a service” world, at least for the moment, and further, that front-end developers tend to want to have the option of using non-Java technologies for the presentation layer, a standard REST API for interacting with content repositories makes sense, whether that’s Sling, whatever Alfresco comes up with, or the best of both.

Maybe the Atom Publishing Protocol is close to what I’m thinking here. Maybe Alfresco thinks so too. I noticed the Abdera JAR was added to the Alfresco Community dependencies fairly recently. Abdera is an Apache incubator project for working with Atom.

We actually have an engagement with Alfresco right now to develop some of the new 3.0 web client modules. When I get some time I’ll explore this idea a little further by checking in on the 3.0 web client team, looking at Abdera, and doing a deeper dive on sling.