Skip to content

Plone Web Services: Things are Looking Up

August 7, 2009

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!

One Comment leave one →
  1. shayan permalink
    August 18, 2009 9:46 am

    Thanks, this answered some questions I had quite nicely.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: