Plone Web Services: Things are Looking Up

A History of Less Than Ideal Solutions

Plone’s web services story has been a mixed bag. On the one hand, it has always supported XML-RPC (included in Python’s standard library since 2.2), a protocol that provides remote procedure calling using HTTP as the transport and XML as the encoding. This is a simple, minimalist, and easy to use way for a Plone site to publish or consume data via a web service. Just write a Python Script or External Method that inputs or outputs a list, dictionary, integer, string, date/time, or boolean, and it can be used anywhere on the web, from any language that has an XML-RPC library (and that’s pretty much every language in use on the web today).

This is powerful and flexible, but it isn’t a “Plone Web Services API” – it’s a mechanism to easily write a custom web service API for a Plone site. For example, a Plone site with biographical data about U.S. presidents could provide XML-RPC methods like getPresidents(startdate, enddate), getBirthDate(president), getInaugurationDate(president), etc. But Plone doesn’t come with a set of generically useful XML-RPC methods like getObject() or getTitle().

The other problem is that XML-RPC is not a mainstream web services protocol, like its successor SOAP which is much more complicated, but embraced by industry. And if you’d like your web services to be RESTful – well, no RPC protocol is RESTful. In fact, Plone can’t do REST-style services at all because the Zope 2 publisher only provides HTTP GET and POST. There won’t be truly RESTful web services in Plone (with support for HTTP PUT and DELETE) until the Zope 2 publisher is retired.

Several projects have tackled improving the Plone web services story by providing a uniform API for getting XML representations of Archetypes content objects:

• CIGNEX implemented SOAP web services for a customer
• The ATRest product used Marshall to generate XML representations
• The GSXML product used Marshall and GenericSetup to generate XML representations

But none of these gained momentum as the Plone web services solution. So when Michael Mulich and Kevin Kalupson at Penn State tackled this problem last spring, they went back to basics.

Roar of the WebLion

The WebLion folks had gotten numerous requests that lent themselves to web services solutions.

• Keep selected content – such as events or news – on 2 or more Plone sites in sync
• A desktop application that consumes Plone content
• A web site that would present Plone content in an Adobe Flash skin

Michael and Kevin decided to solve all these problems with a simple web services API that provides a standard CRUD (create, read, update and delete) interface to Plone content. And because it is so simple, flexible, and available, they chose XML-RPC as the protocol.

The result is wsapi4plone.core (alpha release available on PyPi). Once installed it provides the following XML-RPC calls on any 3.x Plone site:

• post_object
• put_object
• get_object
• delete_object
• get_workflow
• set_workflow
• query
• get_types
• get_schema

With this it is possible not only to mash up bits of Plone content in a web application, but to allow full read-write communication between Plone and another web site.

Atom Publishing Protocol

Although wsapi4plone.core solves the problem, it does not do it in a truly RESTful way. This is the holy grail set forth at the Plone Strategic Planning Summit and discussed at length at the 2008 Plone Conference. The conclusion of these discussions was that Plone should support AtomPub as its web services API – someday when the limitations of the Zope 2 Publisher are removed. For now, the best we can hope for is a separate component that would act as a middleman providing an Atom Publishing Protocol interface to a Plone site.

Google Summer of Code to the rescue! Two of the seven SOC 2009 students are working on a WSGI middleware application that does exactly that. It is called wsapi4plone.parfait, and it will use wsapi4plone.core for its communication with the Plone site. The process looks like this:

This project is a trans-Atlantic collaboration between:

• Mike Mulich (Robert Morris Unversity student) and Kevin Kalupson (Penn State mentor)
• Chelsea Bingiel (University of Chicago student) and Matthew Wilkes (Team Rubber mentor)

You can read more on its CoActivate web page, and you can check out the source code at https://dev.plone.org/collective/browser/wsapi4plone.parfait.

To the Future and Beyond

The SOC project and wsapi4plone.parfait look like the future of Plone web services. With an AtomPub interface to Plone, interoperability with other frameworks becomes possible, especially given the work that’s happening on CMIS (the new Content Management Interface Specification OASIS draft standard). Let’s all cheer the SOC team on!