Page History

...

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.

The existing entities called out as resources below that should be available in some manner as streams are:

• Messages (user-specific) api/users/USERID/messages
• Messages api/messages
• Tags (api/tags)
• Conversations (api/conversations)
• Pools (api/pools)
• Searches ??

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.

References - References -
Dev mailing list thread - http://www.mail-archive.com/esme-dev@incubator.apache.org/msg00976.html

...

• ESME API instance (api/)
  • Session (api2/session)
  • Users (api2/users)
  • 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 ??

(1) Stream interface should be available and use should be encouraged

Each of these bullets represents a set of objects. The resource representing an individual object lives at api/objects/OBJECTID. For example, api/sessionsconversations/SESSIONID1. As much as is reasonable, one would expect to be able to GET (read), POST (create), PUT (update/amend), or DELETE (delete) any individual member of each of these object sets. Going through each of these objects to ask what it would mean to create, read, update, or delete that object may reveal holes in the existing API, some of which I have filled in above.

...

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:

...