-
Project Home
last modified May 30, 2009 by skleinfeldt
Background
This project was initiated at the Plone Strategic Planning Summit. The idea to support an official and complete web services API made it onto the list of PSPS tasks because of a sense that Plone urgently needs a great web services story to be competitive.
The project consists of:
- Defining what "complete web services API" means
- Creating an API specification
- Implementing the API
- Publishing API documentation
- Getting the word out about Plone's great web services story
Possible Approaches
Initial discussions identified the following as possibilities.
- Custom XML schemas (building on GenericSetup)
- Microformats
- Atom Publishing Protocol
- OpenSocial (JavaScript and Atom)
- OAuth for authentication
CMIS
On September 10, 2008, a group including EMC, IBM, Microsoft, Alfresco, Open Text, Oracle, and SAP announced a draft specification for a web services standard for content management - Content Management Interoperability Services (CMIS). Both SOAP and REST bindings are proposed. The draft spec will go to OASIS for ratification. CMIS has hype, buzz and industry support (try a Google search and see EMC, Alfresco ads).
The REST binding for the standard is specified as an extension to Atom and AtomPub - however critics say it is tightly coupled to data model with “protocol extensions that tunnel the Web Services interface through fake-Atom and fake-HTTP” (Roy Fielding). Here is a bit more information about the debate.
Roy Fielding - http://roy.gbiv.com/untangled/2008/no-rest-in-cmis:
- “I am getting tired of big companies making idiotic claims about REST and their so-called RESTful architectures. The only similarity between CMIS and REST is that they both have four-letter acronyms”
- “...unless you expect blogging clients and syndication feeds to be the primary application of CMIS, it would make a lot more sense to define the representations in a microformat of HTML, JSON, YAML, or whatever else best fits the data...”
Sam Ruby - http://www.intertwingly.net/blog/2008/10/01/CMIS:
- Cautiously optimistic
- Feels OASIS TC will address problems
Progress at 2008 Plone Conference
At the 2008 Plone Conference, a Plone Web Services Birds of a Feather session was held. Attendees included Alec Mitchell, Reed O'Brien, Matt Hamilton, Chris Shenton, Sally Kleinfeldt, and others (please add your names). We reached the following conclusions.
- Should we adopt CMIS? or CMIS REST?
- No, reconsider when/if fully baked and made a “standard”
- Should we adopt microformats instead?
- Not systematically, just a view so easy to add for specific cases
- Should we adopt Atom and AtomPub?
- YES! This is a well defined and approved standard in common use today. It will get us a long way toward our goal, and when/if CMIS is approved it should be straightforward to add the CMIS extensions
Relevant Links
Technical Approach
Informal discussions took place at the conference with Reed O'Brien, Alec Mitchell, Chris Shenton, Matt Hamilton, Stefan Rickter, Ian Bicking, Chris McDonough, Kapil Thangavelu, Sean Gilles (IRC), and others. The following ideas emerged.
- Existing Python AtomPub server packages include Amplee and FlatAtomPub. (These include storage, not necessary for a solution that is internal to Plone.)
- Plone today isn't a good fit for REST style services because the Zope2 publisher does FTP, HTTP GET/POST ("browser web"), and WebDAV. Adding anything beyond that is very hard.
- An AtomPub component is probably too big to be a WSGI middleware component, but there could be an Atom Publishing application that lived in a Repoze ecosystem. It could aggregate content from several Plone, Grok, etc. sites. It could also be a way to get around the lack of PUT/DELETE in Plone - acting as a middleman.
- There is an implementation of Atom syndication and AtomPub with GeoRSS for the Zope3 publisher in zgeo.atom; it would make sense to look at this as a possible starting point.
- Within Plone today, we could focus on providing read-only Atom representations. This could take the form of an Atom browser view that would apply to any folderish object and that would provide the Atom compliant XML representation of the folder and its contained objects. This is very similar to the approach taken in ATRest, but using an Atom library instead of Marshall.
- You would get to the Atom view by appending "@@atom" to the URL of an object. You could start at the root of the Plone site and discover all the Atom publishable objects on the site by following the links, since any links given in the Atom representations go to other Atom representations.
- Smart Folders should not be included as folderish objects - they are more like searches and could perhaps be covered by the OpenSearch extensions to Atom.
- Some people had a syndication view of AtomPub functionality, where content owners would need to explicitly declare folders as feeds (similar to the Vice work).
- Others had a more all-inclusive view, thinking all content on the site should automatically provide the AtomPub interface.
Conclusion at 2008 Plone Conference
Implementing truly RESTful web services (GET/POST/PUT/DELETE) for Plone will be a large and complex project, given the limitations of the Zope2 publisher. It isn't realistic to expect it to get done in a sprint or even a series of sprints. The only way it will be implemented is if:
- A customer requires it for a project and hires one of the Plone consulting firms to implement it.
- The Plone Foundation deems it of enough strategic importance to fund the work.
All of the above information is available in a slideshow that was presented at the 2008 Plone Conference sprint.
Plone Symposium East 2009 Update
A Google Summer of Code project for Plone web services has been approved. Participants are:- Penn State: Kevin Kalupson and Mike Mulich
- Team Rubber: Matthew Wilkes and Chelsea Bingiel