REST or a message queue in a multi-tier heterogeneous system?

Question

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?

• Jimmy Hoffa: 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...
• Javier: 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.
• Victor Sergienko: @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.
• Michael Brown: 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.
• Victor Sergienko: @Mike Brown exactly. Please do.

Answer 1

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.

• Victor Sergienko: 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
• Victor Sergienko: 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.

Answer 2

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.

• Victor Sergienko: 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.
• Michael Brown: Wait his book still isn't out...he's been talking about it so long...sounds like another technical author I know. :">
• Jacek Gorgoń: 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.