This page is meant to start as a conceptual design for a 2nd generation REST API for ESME. The idea is to learn from the discussions around and use of the original REST API.

REST API Design

Streams vs.

...

Resources

In the design below, all parts of ESME are modeled as resources, in keeping with a RESTful approach. For things like message streams, this is not an optimal way to model these entities. I'd like to maintain the ability to interface with the full ESME API in a RESTful manner, while also encouraging the use of more optimal interface approaches when this makes sense.

...

One point to note is that many HTTP clients do not currently support the "PUT" or "DELETE" methods, so these may have to be simulated through POST methods with an extra parameter. I think that because of the close mapping to resource verbs, is worth using these methods in the specification and defining the simulation method for the entire API separately.

Streams

There are a lot of ways we can model streams and I'm very interested in input here, as this is not an area that I am familiar with (though I hope to learn quickly from some of the experts on the project). Options for interfacing to streams that I have seen:

• XMPP - http://xmpp.org/
• AMQP - http://jira.amqp.org/confluence/display/AMQP/Advanced+Message+Queuing+Protocol
• HTTP
  • Polling (bad)
  • Comet/long-polling - Bayeux - http://svn.cometd.com/trunk/bayeux/bayeux.html
  • Reverse HTTP - http://www.reversehttp.net/

Resource/Object/Stream Hierarchy

The above is based on a rough object hierarchy as follows:

...