...
Streams vs. Resources
In the design below, all parts of ESME are modeled as resources, in keeping with a RESTful approach. Our streaming resources (also thought of as delta-queue resources) are collections that are only additive. We have defined a general streaming interface that strives to be RESTful while prioritizing the performance benefits of streams.
...
- ESME API instance (api/)
- Session (api2/session)
- Users (api2/users)
- Specific User (api2/users/USERID)
- User's tokens (api2/users/USERID/tokens)
- Specific User (api2/users/USERID)
- Messages posted by logged in user (api2/user/messages) (1)
- Users followed by logged in user (api2/user/followees)
- Users following logged in user (api2/user/followers)
- Trackers belonging to logged in user (api2/user/tracks)
- Messages from a track (api2/user/tracks/TRACKID/messages) (1)
- Actions belonging to logged in user (api2/user/actions)
- Messages (api2/messages) (1)
- Tags (api2/tags)
- Messages posted to a tag (api2/tags/TAG/messages) (1)
- Conversations (api2/conversations)
- Messages posted to a conversation (api2/conversations/CONVERSATIONID/messages) (1)
- Pools (api2/pools)
- Users associated with a pool (api2/pools/POOLID/users)
- Messages posted to a pool (api2/pools/POOLID/messages) (1)
- Searches ?? (1)
- Trends ??
...
Resource | Method | Description/Payload schema/Response schema | Streaming? | Admin Only? |
---|---|---|---|---|
api2/session | GET,POST,DELETE | Post parameter: token |
| |
api2/users | GET, POST | Post parameters: nickname, password - returns: user created |
| POST |
api2/users/USERID | GET |
|
| |
api2/users/USERID/tokens | GET, POST | Post parameters: description - returns: token created |
| GET, POST |
api2/user/messages | GET,POST | Post parameters: message, via (opt), pool (opt), realm (opt), metadata (opt), tags (opt), replyto (opt) | Yes | |
api2/user/tags/TAG | GET |
|
| |
api2/user/tags/TAG/messages | GET |
| Yes | |
api2/user/followers | GET |
|
| |
api2/user/followees | GET,POST | Post parameter: userId |
| |
api2/user/followees/USERID | DELETE |
|
| |
api2/user/tracks | GET,POST | Post parameter: track (regex) |
| |
api2/user/tracks/TRACKID | GET,DELETE |
|
| |
api2/user/tracks/TRACKID/messages | GET |
| Yes | |
api2/user/actions | GET,POST | Post parameter: name, test, action |
| |
api2/user/actions/ACTIONID | GET,PUT,DELETE | Put parameter: enabled (boolean) |
| |
api2/messages/MESSAGEID | GET |
|
| |
api2/messages | GET,POST |
| Yes | |
api2/conversations/CONVERSATIONID | GET |
|
| |
api2/conversations/CONVERSATIONID/messages | GET,POST |
| Yes | |
api2/pools | GET,POST |
|
| |
api2/pools/POOLID | GET,DELETE |
|
| |
api2/pools/POOLID/users | GET,POST | Post parameters: realm, userId, permission |
| |
api2/pools/POOLID/users/USERID | DELETE |
|
| |
api2/pools/POOLID/messages | GET,POST |
| Yes |
One point to note is that some 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.
...
Note on the call: api2/user/messages (http://esmecloudserverapache.dickhirsch.staxapps.net/api2/user/messages?via=SAPRiver&tag=bob&message=User+')
That call uses "tag", not "tags". Looking at the API2 code, the parameter name needs to be "tags".
When it does work, I think the behavior may be a bit misleading, as tags added using the tags parameter do not necessarily show up in the message at all. So make sure to keep an eye on the tag cloud or go to the page for the specific tag you are trying to add and see if it shows up there.
...
Streams
There are a lot of ways we can model streams and I'm very interested in input here. 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/
- PubSubHubBub? - possibly via Reverse HTTP - http://www.reversehttp.net/demos/endpoint.html
Authorization and roles
Certain API methods are only available to certain roles, as defined in property files. If an API method has a notation in the "Admin only?" column, this means that the user attempting to interact with that API method must have the proper role assigned in the relevant property file.
For example, take a look at the test.default.props file in the /server/resources/props directory.
Or, for example, create a prod.default.props file in the "server/resources/props" directory. In this file, add the line "role.myuser=integration-admin", where
"myuser" is the username that you want to have super-powers.
("integration-admin" is what we're calling the role.)
ESME HTTP Comet/long-polling implementation for streams
...
Once this interface is implemented where planned for a URL, the "Yes" above in the "Streaming?" column will be bolded.
...
...
...
Streams/Message-queues in ESME and in general
...
...
Formats
Request formats
Format specification
...