Come progettare un gateway HTTP RESTful per un protocollo che richiede connessioni persistenti?

Question

Sto lavorando con un protocollo client/server persistente e ho bisogno di progettare un gateway RESTful. Non ho molta esperienza nella progettazione di interfacce REST e non capisco come dovrei gestire (in modo RESTful) gli ID di sessione necessari per mantenere le connessioni persistenti sul server e come dovrei rappresentare lo stato del server come risorse.

Sto chiedendo questo perché non voglio finire con un risultato RPC-ish che sembra "RESTful".

Contesto specifico del problema: desidero migliorare il gateway REST ZooKeeper esistente per supportare nodi e orologi effimeri. Un nodo effimero esiste mentre il client è connesso al server.

Grazie.

Answer 1

Il modo in cui l'ho fatto in passato segue un modello "ticket" o "scontrino". Il servizio REST accetta richieste di una risorsa (un nome di report, un znode, ecc.) E restituisce un ticket. Questo ticket (di solito un UUID o qualcosa di simile) può essere utilizzato per rappresentare una sessione. Le richieste successive utilizzano questo ticket per verificare lo stato delle loro richieste. Per garantire una scadenza adeguata dei biglietti, si verifica uno dei due casi; puoi ritirare i biglietti o, una volta ricevuto un risultato, il cliente deve fornire un ACK (riconoscimento) al servizio.

ex.

Richiesta: GET/Zookeeper/Znode/effimero/foo Risposta: 1234-1234-1234-1234

Richiesta: GET/Zookeeper/Stato/1234-1234-1234-1234 Risposta: LAVORO (o disponibile o bloccato o NOTREADY o fallito ...)

Richiesta: GET/Zookeeper/stato/1234-1234-1234-1234 risposta: acquisita (o disponibili o OK o il successo o un certo valore (s) ...)

Richiesta: GET/zookeeper/acknowledge/1234-1234-1234-1234 Risposta: OK (o il biglietto UNKNOWN, etc.)

interessanti messaggi gestibilità:

Richiesta: GET/zookeeper/sessioni (o/biglietti) Risposta: [1234, 5668, ...]

Richiesta : GET/zookeeper/kill/ Risposta: OK (o SCONOSCIUTO o FALLITO ...)

Questo ha funzionato molto, molto bene. Ciò significa, tuttavia, il servizio REST è stato che rende più complicato il bilanciamento del carico. Ho usato un protocollo che garantisce che un ID server venga restituito con ogni risposta e se il client riceve un ID server diverso e un ticket SCONOSCIUTO, si presume che il servizio con cui si stava parlando sia morto e ricomincia da capo. Ciò implica un appiccicoso bilanciamento del carico (ad esempio il round-robin non funzionerebbe qui). Il servizio REST deve essere multithreading per supportare l'esecuzione di queste richieste in parallelo e fornire accesso a un database ticket (di solito in memoria, struttura dati hashtable sincronizzata) e un thread timeout sessione/ticket.

Spero che questo aiuti.