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 return202 Accepted
to some async call only to find out that necessaryHome
connection is broken and there should have been503
; Home
needs to send messages toClient
.Client
will have to pollFront-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.