REST o una coda di messaggi in un sistema eterogeneo a più livelli?

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 Front-endtramite Websocket o un lungo sondaggio (questo è il primo posto in cui stiamo violando REST. In seguito peggiorerà ancora) . Front-endper lo più tunnel Clientrichieste di Homeconnessione e gestisce alcune delle chiamate stesse. A volte Homeinvia notifiche a Client.

Front-ende Homehanno sostanzialmente la stessa API; Clientpotrebbe connettersi Homedirettamente, tramite LAN. In questo caso, è Homenecessario registrare alcune Clientazioni su Front-endse stesso.

I pro per REST in questo sistema sono:

• REST è leggibile dall'uomo;
• REST ha una mappatura ben definita di verbi (come CRUD), nomi e codici di risposta agli oggetti del protocollo;
• Funziona su HTTP e passa tutti i possibili proxy;

I contrasti REST sono:

• Abbiamo bisogno non solo di uno stile di comunicazione richiesta-risposta, ma anche di un abbonamento di pubblicazione;
• I codici di errore HTTP potrebbero non essere sufficienti per gestire gli errori di comunicazione a tre livelli; Front-endpotrebbe tornare 202 Acceptedad alcune chiamate asincrone solo per scoprire che la Homeconnessione necessaria è stata interrotta e che avrebbe dovuto esserci 503;
• Homedeve inviare messaggi a Client. Clientdovrà effettuare il polling Front-endo mantenere una connessione.

Stiamo prendendo in considerazione WAMP / Autobahn su Websocket per ottenere la funzionalità di pubblicazione / sottoscrizione, quando mi è sembrato che sembri già una coda di messaggi.

Vale la pena valutare una sorta di coda di messaggistica 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?

Se hai la connettività, vai con una coda di messaggi - anche se devi definire i tuoi protocolli (difficilmente un compito difficile!) Per inviare messaggi di una struttura e un formato particolari.

Il problema con la manutenzione è che in genere il client e il server sono costruiti separatamente, quindi è necessario fare attenzione a mantenere entrambe le estremità utilizzando le stesse definizioni dei messaggi, ma se non si è abbastanza organizzati, utilizzare semplicemente lo stesso XML che si utilizzerebbe nel REST servizio.

Se hai problemi di connettività su Internet, con la sola porta 80 e http e le comunicazioni "unidirezionali", un sistema in stile REST è probabilmente il migliore. Invia e fai polling, oppure ottieni un websocket per i dati di callback, ma in genere architetti il ​​tuo sistema come client / server. Se hai la possibilità di ottenere la connettività, i sistemi di messaggistica sono fantastici.

Andrei con ZeroMQ per un sistema di messaggistica, abbastanza configurabile per girare in tutti i tipi di scenari, compresi quelli a tolleranza d'errore. Non sono sicuro che funzioni su http però.

Sembra che Autobahn si adatti perfettamente a ciò che stai cercando di fare. Ci sono anche altri strumenti disponibili. Dai un'occhiata al bus di servizio di Windows Azure (che ha framework client per Java, .NET, PHP, Python, NodeJS e Ruby).

Mentre i messaggi di riposo integrati sono utili. Scoprirai che la tua applicazione supererà le operazioni CRUD di base. Ad esempio se la tua domanda fosse un sistema bancario. Invece di

Aggiorna acc. 54321 Saldo = Saldo - 20,00 Aggiorna acc. 98765 Saldo = Saldo + 20,00

Probabilmente vorresti un singolo messaggio come

Trasferisci 20.00 dall'account 54321 all'account 98765

È meglio scoprire questo impedimento con REST ora piuttosto che dopo. Dai un'occhiata a Greg Young's Event Centric che spiega come creare un modello più ricco di messaggistica all'interno della tua applicazione.