Architecture – REST vs Message Queue in Multi-Tier Systems

Architecturemessage-queuerestweb serviceswebsockets

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?

Best Answer

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.

Related Topic