Sto progettando un'API REST per un sistema a tre livelli come: Client application
- > Front-end API cloud server
- > user's home API server (Home)
.
Home
è un dispositivo domestico e dovrebbe mantenere la connessione a Front-end
tramite Websocket o un lungo sondaggio (questo è il primo posto in cui stiamo violando REST. . Front-end
principalmente tunnels Client
richieste a Home
connessione e gestisce alcune delle chiamate stesse.
A volte Home
invia notifiche a Client
.
Front-end
e Home
hanno fondamentalmente la stessa API; Client
potrebbe collegarsi a Home
direttamente, tramite LAN. In questo caso, Home
deve registrare alcune azioni Client
su una Front-end
stessa.
I vantaggi di REST in questo sistema sono:
- REST è leggibile dall'uomo;
- REST ha una mappatura dei verbi ben definita (come CRUD), nomi e codici di risposta agli oggetti del protocollo;
- Funziona su HTTP e passa tutti i possibili proxy;
I contras REST sono:
- Abbiamo bisogno non solo di uno stile di comunicazione richiesta-risposta, ma anche di una pubblicazione-sottoscrizione;
- I codici di errore HTTP potrebbero non essere sufficienti per gestire errori di comunicazione a tre livelli;
Front-end
potrebbe restituire202 Accepted
a qualche chiamata asincrona solo per scoprire che la connessioneHome
necessaria è interrotta e ci dovrebbe essere503
; -
Home
deve inviare messaggi aClient
.Client
dovrà interrogareFront-end
o mantenere una connessione.
Stiamo considerando WAMP / Autobahn su Websocket per ottenere funzionalità di pubblicazione / sottoscrizione, quando mi ha colpito che sembra già una coda di messaggi.
Vale la pena valutare una sorta di coda di messaggi come trasporto?
Sembra che i contras della coda dei messaggi siano:
- Dovrò definire personalmente i verbi CRUD e i codici di errore a livello di messaggio.
- Ho letto qualcosa su "costi di manutenzione più elevati", ma cosa significa?
quanto sono serie queste considerazioni?