dcaruana

Alfresco Web Services Revisited

Blog Post created by dcaruana Employee on Jun 28, 2007

   Alfresco first introduced its Web Services for Content Management back in July 2005, almost two years ago. In those two years the software world has radically changed. Think back to July 2005. Google Maps API had only just been released, the whole Web 2.0 thing had only just started to roll, Mark Baker and company were way ahead of the curve while the rest of us believed in SOAP, and had you heard of the Arctic Monkeys? Today, it's all about mash-ups, rich applications, scripting and the network as the platform. And of course, you can't ignore the current REST Fest, now we've all caught up - could it be that SOAP slips away to be replaced with what was already there.

  

   Given this trend, ECM should rethink the way it provides Web Services.  Imagine being able to expose your enterprise content resources (folders, documents, searches, categories, versions, discussions, workflows etc) to your network with the minimum of effort; distributed resources that can be retrieved, managed, mashed by any part of your enterprise software suite. Imagine being able to build custom content services specifically for your domain and application needs without Java knowledge, tooling, compilation, stub generation or XSD.

  

   Here's an example of how such a resource (a folder) might be exposed (as an ATOM feed) via a HTTP URL:

  

Description File: folder.get.desc.xml
<webscript>
  <shortname>Folder listing</shortname>
  <url>/folder/{path}</url>
  <authentication>guest</authentication>
</webscript>

Execution Logic File: folder.get.js
model.folder = search.lookupByPath(url.extension);
if (model.folder == undefined)
{
  status.code = 404;
  status.redirect = true;
}

Response Template File: folder.get.atom.ftl
<?xml version='1.0' encoding='UTF-8'?>
<feed xmlns='http://www.w3.org/2005/Atom'>
  <title>Folder: ${folder.displayPath}/${folder.name}</title>
  <updated>${xmldate(date)}</updated>
<#list folder.children as child>
  <entry>
    <title>${child.name}</title>
    <link rel='alternate' href='${child.url}'/>
    <icon>${absurl(url.context)}${child.icon16}</icon>
    <id>urn:uuid:${child.id}</id>
    <updated>${xmldate(child.properties.modified)}</updated>
    <summary>${child.properties.description!''}</summary>
    <author><name>${child.properties.creator}</name></author>
  </entry>
</#list>
</feed>

Normally, I don't post code in a blog, but this demonstrates how simple it could be to implement a content web service backed by an ECM Repository.

And this leads to Alfresco's new web services for Content Management.  With our soon-to-be-released v2.1, the installation of the above service is performed by just copying the 3 files to the Alfresco Repository Data Dictionary.  The service is then accessible via a HTTP GET e.g. to retrieve an ATOM feed for Alfresco's Company Home folder, issue...

http://<host>:<port>/alfresco/service/folder/Company%20Home

This is a simple example of an Alfresco v2.1 Web Script. An Alfresco Web Script provides a service on the web where the service may perform any function, but are particularly suited to Content Management as they're backed by all Alfresco Repository features. They're ideal for building content access & update APIs, simple UI components such as content-oriented Portlets, and integration adaptors. As an example, Alfresco's v2.1 OpenSearch has been re-hosted as a series of Web Scripts.

Each Web Script is bound to a HTTP method & custom URL Template and implemented with XML (description), Javascript and Templates. A library of URLs may be composed to provide a complete (RESTful) HTTP API. Support for multiple content-types such as ATOM, JSON (including callbacks) is provided, as well as authentication, response status codes, a simple customization model, and pluggable Web Script Runtimes.

The latest Alfresco nightly builds and SVN revisions provide the full Web Script framework.  Try it out and give us feedback before we go final.

Now, you can mash your enterprise content.

Outcomes