Wie wird ein RESTful-HTTP-Gateway für ein Protokoll entworfen, für das persistente Verbindungen erforderlich sind?

Question

Ich arbeite mit einem dauerhaften Client/Server-Protokoll und ich muss ein RESTful-Gateway entwerfen. Ich habe nicht viel Erfahrung beim Entwerfen von REST-Schnittstellen und ich verstehe nicht, wie ich (auf REST-Weise) die Sitzungs-IDs behandeln soll, die zum Aufrechterhalten persistenter Verbindungen auf dem Server erforderlich sind und wie ich den Serverstatus als Ressourcen darstellen soll.

Ich frage das, weil ich nicht mit einem RPC-ish-Ergebnis enden möchte, das "RESTful" aussieht.

Problemspezifischer Kontext: Ich möchte das vorhandene ZooKeeper REST-Gateway verbessern, um ephemere Knoten und Uhren zu unterstützen. Ein ephemeraler Knoten existiert, während der Client mit dem Server verbunden ist.

Danke.

Answer 1

Die Art und Weise, in der ich das in der Vergangenheit getan habe, folgt einem "Ticket" oder "Quittungs" -Muster. Der REST-Dienst akzeptiert Anforderungen für eine Ressource (einen Berichtsnamen, einen Znode usw.) und gibt ein Ticket zurück. Dieses Ticket (normalerweise eine UUID oder etwas Ähnliches) kann zur Darstellung einer Sitzung verwendet werden. Nachfolgende Anfragen verwenden dieses Ticket, um den Status ihrer Anfragen zu überprüfen. Um sicherzustellen, dass die Tickets ordnungsgemäß verfallen, tritt einer von zwei Fällen auf; Sie können Tickets ausbuchen oder bei Empfang eines Ergebnisses muss der Client eine Bestätigung (ACK) an den Service zurückgeben.

ex.

Anfrage: GET/Tierpfleger/ZNODE/ephemeren/foo Antwort: 1234-1234-1234-1234

Anfrage: GET/zookeeper/status/1234-1234-1234-1234 Antwort: ARBEITS (oder UNAVAILABLE oder blockierter oder NOTREADY oder nicht ...)

Anfrage: GET/zookeeper/status/1234-1234-1234-1234 Antwort: Acquired (oder AVAILABLE oder OK oder SUCCESS oder einen anderen Wert (e) ...)

Anfrage: GET/zoekeeper/bestätigen/1234-1234-1234-1234 Antwort: OK (oder UNKNOWN TICKET, etc.)

Interessante Verwaltbarkeit Nachrichten:

Anfrage: GET/Tierpfleger/Sitzungen (oder/Tickets) Antwort: [1234, 5668, ...]

anfordern : GET/zoekeeper/kill/ Antwort: OK (oder UNBEKANNT oder FEHLGESCHLAGEN ...)

Das hat sehr, sehr gut funktioniert. Dies bedeutet jedoch, dass der REST-Dienst statusbehaftet ist, was die Lastverteilung schwieriger macht. Ich habe ein Protokoll verwendet, das sicherstellt, dass bei jeder Antwort eine Server-ID zurückgegeben wird, und wenn der Client eine andere Server-ID und ein UNKNOWN-Ticket erhält, gehen Sie davon aus, dass der Dienst, mit dem Sie gesprochen haben, gestorben ist. Dies impliziert einen Lastenausgleich (d. H. Round-Robin würde hier nicht funktionieren). Der REST-Dienst muss multi-threaded sein, um die parallele Ausführung dieser Anforderungen zu unterstützen und den Zugriff auf eine Ticketdatenbank (normalerweise im Speicher, synchronisierte Hashtabellen-Datenstruktur) sowie einen Sitzungs-/Ticket-Zeitüberschreitungs-Thread bereitzustellen.

Hoffe, das hilft.