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.
Home sends notifications to
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
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;
202 Acceptedto some async call only to find out that necessary
Homeconnection is broken and there should have been
Homeneeds to send messages to
Clientwill have to poll
Front-endor to maintain a connection.
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?