One of the projects I'm working on, Mollom, is a great example of a Software As A Service (SAAS) project. The core functionality of Mollom, checking whether content is spam or not, is applicable in a number of areas, and can be accessed by a number of clients. That number of clients will likely increase in the future, as we added a REST interface to the Mollom API.
Until now, clients that want to talk to Mollom need to use an XML-RPC interface. While the XML-RPC interface is still supported, we added a REST interface that provides the same functionality. There were a number of reasons why we did this:
- the popularity of REST is increasing. Many services offer a REST interface, and client developers are used to it.
- it is human-readable and developer friendly.
- a bunch of tools exists, allowing to call REST endpoints from within any programming language.
- easy integration with the oAuth Authentication Protocol.
My own blog is using the REST interface for some months now, and we're now adding beta testers in order to get feedback and to tweak the interface and implementation.
We have a test-implementation with an endpoint that is available at http://dev.mollom.com/v1 and the specification is described at http://mollom.com/api/rest. This test-implementation is different from the production implementation:
- You don't need a real mollom key, you can create one using the API itself
- The behavior of some calls is different, and allows you to test your client. As an example, sending a content with postBody containing "spam" will result in a spam-response -- this specific behavior will be described later.
- The test-implementation is not using load balancing and failover. The goal of the test-implementation is not to examine behavior under stress-tests. Good enough, the Mollom production servers are more robust.
Developers who are familiar with accessing REST services should be able to start using the test implementation right away. We're in the process of making more code samples available. In a follow-up post, I'll go deeper on some of the technicalities behind this REST interface (we use Glassfish 3.1.1 with Jersey 1.8 with oauth support). In the meantime, feedback is very welcome!