I'm designing a REST API for a three-tier system like: Client application -> Front-end API cloud server -> user's home API server (Home).

Home is a home device, and is supposed to maintain connection to Front-end via Websocket or a long poll (this is the first place where we're violating REST. It gets even worse later on). Front-end mostly tunnels Client requests to Home connection and handles some of the calls itself. Sometimes Home sends notifications to Client.

Front-end and Home have basically the same API; Client might be connecting to Home directly, over LAN. In this case, Home needs to register some Client actions on a Front-end itself.

Pros for REST in this system are:

  • REST is human-readable;
  • REST has a well-defined mapping of verbs (like CRUD), nouns and response codes to protocol objects;
  • It works over HTTP and passes all the possible proxies;

REST contras are:

  • We need not only a request-response communication style, but also a publish-subscribe;
  • HTTP error codes might be insufficient to handle three-tier communication errors; Front-end might return 202 Accepted to some async call only to find out that necessary Home connection is broken and there should have been 503;
  • Home needs to send messages to Client. Client will have to poll Front-end or to maintain a connection.

We are considering WAMP/Autobahn over Websocket to get publish/subscribe functionality, when it struck me that it's already looking like a message queue.

Is it worth evaluating a sort of messaging queue as a transport?

Looks like message queue contras are:

  • I'll need to define CRUD verbs and error codes myself on a message level.
  • I read something about "higher maintenance cost", but what does it mean?

how serious are these considerations?

  • 1
    Why do you have a cloud server in the mix? Sounds like all it does is redirect which makes me think it should plausibly live on the same machine as the home server... Oct 15, 2013 at 13:22
  • 3
    when you analyze message queues, note that most of them are optimized for private LANs: low-latency, controlled clients, protected network, etc. exposing the queue to internet can be a huge security problem.
    – Javier
    Oct 15, 2013 at 13:34
  • @Jimmy Hoffa valid point, thanks. That's right, but not completely. It's a common database, storage and so on. @Javier thank you, it's a good part of an answer. Oct 15, 2013 at 13:41
  • Is the Home server meant to be run at some user's home and the front-end in the cloud? The home connects to front-end and client sends messages to home via front-end. If I understand your design correctly, I can give a god answer. Oct 15, 2013 at 14:30
  • @Mike Brown exactly. Please do. Oct 15, 2013 at 14:44

2 Answers 2


If you have the connectivity, go with a message queue - although you have to define your own protocols (hardly a difficult task!) to send messages of a particular structure and format.

The problem with maintenance is that typically the client and server are built separately so you need to be careful to keep both ends using the same message definitions, but if you're not organised enough, just use the same XML you would use in your REST service.

If you have connectivity issues over the internet, with port 80 and http only and 'unidirectional' comms then a REST style system is probably the best. Send and poll, or get a websocket going for callback data, but generally architect your system be be client/server. If you have the ability to get the connectivity, then messaging systems are great.

I'd go with ZeroMQ for a messaging system, its configurable enough to twist in all manner of scenarios, including fault-tolerant ones. I'm not sure that it works over http though.

  • Thanks. What I found after @Javier comment: ØMQ seems not to support encryption itself atm: zeromq.org/area:faq#toc8 though RabbitMQ does: rabbitmq.com/ssl.html Oct 15, 2013 at 15:01
  • I don't know if I have the connectivity. Home is a user home device, and Client is a smartphone over Wi-Fi or 3G. One big part of the question is my ignorance about a NAT traversal methods. Oct 15, 2013 at 15:07

It looks like Autobahn fits nicely with what you're trying to do. There are other tools available as well. Check out the Windows Azure Service Bus (which has client frameworks for Java, .NET, PHP, Python, NodeJS, and Ruby).

While the built in rest messages are useful. You'll find that your application will outgrow basic CRUD operations. For instance if your application were a banking system. Instead of

Update Acct 54321 Balance = Balance - 20.00 Update Acct 98765 Balance = Balance + 20.00

You'd probably want a single message like

Transfer 20.00 from account 54321 to account 98765

It's best that you discover this impediment with REST now rather than later. Check out Greg Young's Event Centric which discusses how to create a richer model for messaging within your application.

  • Thanks a lot. Indeed we might outgrow CRUD, though not very soon, our domain is pretty simple now. BTW the book is not published yet, trying to find some matherials in Greg's blog... I think it's good I don't have to use Microsoft technology for that. Oct 15, 2013 at 20:17
  • Wait his book still isn't out...he's been talking about it so long...sounds like another technical author I know. :"> Oct 15, 2013 at 20:38
  • 1
    For the record, REST approach would be to have a Transfer resource that you create. Or even a TransferRequest that can pass or not. REST gets tricky in some cases, but this is not one of them. Jan 14, 2015 at 13:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.