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-endpotrebbe restituire202 Accepteda qualche chiamata asincrona solo per scoprire che la connessioneHomenecessaria è interrotta e ci dovrebbe essere503; -
Homedeve inviare messaggi aClient.Clientdovrà interrogareFront-endo 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?