views:

80

answers:

1

Hi,

I'm trying to find relevant best practices/specs/literature/etc. to the general problem of using a restful API (say, a standard Rails app) behind a non-restful facade, like a XMPP API or a websockets channel.

For example, I've got a restful Rails app, and I want to expose a read-only asynchronous interface. It's pretty straightforward stuff, with the Rails app pushing to a Redis pubsub channel, which is in turn consumed from node.js, and sent to a websocket channel (1). Now, how would I best go about making this asynch api read/write? I'm thinking of the client sending to the server, over the websockets channel, what basically would amount to serialized http requests or lightweight json-encoded payloads that would in turn go to a Resque queue and then would be parsed from the main app, but I'd like to know if there's previous work/specs/architectures I can build upon, or simply more elegant approachs I might be overlooking.

(1) Obviously, you could replace 'websockets' with 'xmpp' and the general concern, restful apps behind non-restful interfaces, would still apply.

Thanks in advance for any help.

A: 

I'm not sure there really is any difference except in the method of call/response.

For example, in the web world all calls to a REST interface are normally made from the browser where any state tracking is done server side as your dealing with a web client. So the client interface normally sends a lot of data (either directly or indirectly via cookie) to allow the server to reconstruct the context of the call.

With the call happening over XMPP (bosh or direct) or Websockets you will need to do the same because the client will be talking to an intermediate, the XMPP Component or bot, that receives the stanza's that make up the request, gathering any stored state and then passing that on to the REST.

In the most basic form the XMPP bot/component will just take the incoming stanza, translate it to a REST call, make that call and then package up the result.

bear