[zeromq-dev] HTTP -> 0MQ XREQ proxy example.

[Robert G. Jakabosky]

On Sunday 20, Pieter Hintjens wrote:
> On Sun, Mar 20, 2011 at 4:22 PM, Pieter Hintjens <ph at imatix.com> wrote:
> 
> For what it's worth, there's a RESTful transport layer (RESTTL) I
> designed at http://restms.org, which could be used as the basis for
> this. The advantages of using REST is that everything will be properly
> cached and proxied. The disadvantage is that it is more complex than
> it could be. For client apps it's trivial either way, any stack would
> be packaged into a binding. It should be possible to emulate the 0MQ
> API pretty directly IMO.
>
> Robert, since you're already writing HTTP server code, would you give
> an opinion on using RESTTL as the basis? Imagine the goal is to
> provide a JavaScript binding which provides 0MQ sockets, bridged over
> HTTP.

That looks way more complex then what I was thinking about.  Exposing the 
whole 0MQ API to the HTTP client would add the need for authentication or at-
least much more complex HTTP server rules.

Here are some simple use-cases I can think of:
The HTTP server's config to define the semantics of each url.

1. HTTP server -> PUB/SUB:
* The client POSTs messages to a publish url:
http://server/pub/subject
* The client makes a long-poll GET request on the subscribe url:
http://server/sub/subject
To support subscribing to multiple subject the client could send a POST 
request to the subscribe url with a list of all the subject it is interested 
in or the server could maintain some session for each client.  WebSockets or 
one of the other client-side socket methods could be used instead of long-poll 
GET requests.

2. HTTP server -> XREQ: (this is basically what my proxy does)
This should simply map one HTTP request/response to one 0MQ request/response.  
For GET requests send the full url or the query string as the 0MQ request and 
the 0MQ response as the HTTP response body.  The server could be configured to 
include the HTTP headers as the first part of the 0MQ request/response 
messages.  This is not for replacing FastCGI or some other web server to 
application server protocol, since it wouldn't support streaming the response 
back to the client.  This could be used to submit a job to a distributed pool 
of backend workers.

3. XREP -> HTTP client:
With this you could re-use existing web-applications running on a HTTP server 
as backend workers for a work queue.  This is like a reverse HTTP proxy which 
load-balances across multiple backend HTTP servers.

4. HTTP server -> PUSH:
This is like #2 except you don't care for a response.  This would work for 
pushing messages onto a queue.

5. HTTP server -> PULL:
Basically the HTTP server would be a queue server that clients could GET work 
from.

These are simple patterns that developers could pick from and customize as 
needed.  I think the PUB/SUB one would be of interest to web-developers that 
want a simple way to push messages out to the javascript on their website 
(i.e. notices, chat, or IMs).

I am not sure what would be the best way to encode 0MQ's multipart messages in 
the HTTP message bodies.  My example proxy just puts the whole POST body into 
one part and for the response it puts a newline between each part.  I did it 
that way just to get something working as an example.

-- 
Robert G. Jakabosky