Websockets - Request/Response

[LudwigBr]

Guten Morgen,

ich habe eine etwas unkonkretere Frage, deshalbe hab ich mal den Bereich Software-Design gewählt.

In einem noch in der Entwicklung befindlichen Projekt werde ich Websockets einsetzen, damit Daten "unkompliziert" vom Server zum Client gepusht werden können.
Nun gibt es darüber hinaus aber auch einige übliche Request-Response Anwendungsfälle, in denen der Client Daten abfragt oder ändert. Mein Gedanke war die ebenfalls über die bestehende Websocketverbindung zu schicken und keine extra ("teuren") HTTP Verbindungen aufzubauen.
Aktuell plane ich beim Request eine Route mitzuschicken und dann analog zum Http Routing darauf folgend eine Response zusammenzubauen. Dem Response würde ich noch einen eindeutigen Namen mitgeben, damit die Nachricht beim Client zugeordnet werden kann.
Haltet ihr das grundsätzlich für sinnvoll Websockets mit so einem Request-Response Schema zu erweitern oder sollte ich dann doch einfach AJAX nehmen?

Ich freue mich auch über verlinkte Diskussionen zu dem Thema, meine googeleien dazu waren nur mäßig erfolgreich.
Gefunden habe ich https://github.com/swagger-api/swagger-socket. Das klingt recht genau nach meinen Anforderungen, scheint mir aber nichtmehr unterstützt zu werden.
Außerdem noch http://wamp-proto.org/ was versucht ähnliche "Probleme" zu lösen.

Liebe Grüße

[tomBuilder]

Möglicherweise hilft Dir das
https://github.com/bwoebi/http-websocket

aus der Community was Dir möglicherweise einen besseres Support bringt.
für die ersten Schritte und tests.

Möglicherweise auch das:
http://socketo.me/docs/flow

gruß

[JaMa]

Ich habe vor kurzem erst selber genau sowas gemacht. Allerdings unter Java.

Dazu habe ich einem Request (JSON) ein Property "route" mit übergeben. Das habe ich dann auf Serverseite für das Routing genutzt.
Zusätzlich habe ich in den Request noch eine UUID gepackt, welche im Response auch wieder zurückgegeben wurde. So konnte ich auf Client Seite die Responses wieder einfach zuordnen.
Im Endeffekt konnte ich dann in den Controllern arbeiten wie wenn ich HTTP Requests hätte (Parameter, Rückgabe, etc.).
Natürlich ist die Kommunikation dann nicht standardisiert, d.h. du musst für alles selber ein Schema defininieren (Fehler, Payload, etc.).

Prinzipiell finde ich das ganze cool wenn sowieso schon eine WebSocket Verbindung besteht (also nicht nur für Request-Responses). Aber auch wirklich nur wenn es sich auf wesentliche Funktionalitäten (Daten senden/abholen) beschränkt. Sobald du da anfängst HTTP-Header nachzubauen bist du mit HTTP definitiv besser dran.

EDIT:
Möchte auch noch einen kleinen (wenig überraschenden) Performance Vergleich hier anbringen:
http://blog.arungupta.me/rest-vs-web...on-benchmarks/

[VPh]

Haltet ihr das grundsätzlich für sinnvoll Websockets mit so einem Request-Response Schema zu erweitern oder sollte ich dann doch einfach AJAX nehmen?

Ich würde Ajax nehmen. Der entscheidende Grund wäre dabei für mich das Wort "einfach"
Es hält auch die Schnittstelle sauberer indem man dann nur "bestimmte" Messages vom Client an den Server sendet. Wenn du da eine Message für "myAbitraryRequest" definierst, den Request nach einer Route durchsuchst etc. könnte es IMO schnell unübersichtlich werden.

Das sind aber nur meine oberflächlichen Bedenken dazu. Wenn sich sowas sauber implementieren lässt, top.

[lottikarotti]

Ich denke dass es grundsätzlich einfacher ist Ajax-Requests, bzw. die Infra einer REST-API, zu skalieren. Deshalb nutzen wir Websockets nur da wo sie einen klaren Vorteil bringen (Echtzeit, Overhead, ..).

[LudwigBr]

Danke für die Antworten, dass zeigt mir das meine Gedanken dazu wohl zumindestens nicht völlig abwägig waren.

Die Bedenken werde ich mur noch etwas durch den Kopf gehen lassen. Die Skalierbarkeit ist natürlich kein unwichtiger Punkt, u.a. da ich die Request/Response Nachrichten in erster Linie der Performance (bzw. Reduzierung des Overheads) wegen auch über die Sockets übertragen will.

Allerdings unter Java.

Ich hab die kürzliche Diskussion über Java vs. Php hier mitgelesen und da scheiden sich die Geister. Gabs hier im speziellen Anwendungsfall konkrete Gründe?

Danke auch für die Beschreibung des Backends, da hatte ich ähnliche Vorstellungen von. Mich würde noch etwas interessieren wie du JaMa den Empfang im Frontend einigermaßen sauber abgewickelt hast.

[JaMa]

Java war Vorgabe
Im Prinzip macht es aber keinen Unterschied ob das ganze mit Java, PHP, ... realisiert worden wäre.

Ich würde das auch nur einsetzen, wenn auch wirklich sowieso eine WebSocket Verbindung gebraucht wird. Den Overhead von HTTP würde ich nicht unbedingt als ausschlaggebendes Kriterium herziehen, da sich dieser immer mehr relativiert dank besser werdenden Internetverbindungen (mobil als auch "stationär"). Das ganze wird erst wirklich ausschlaggebend wenn du einen hohen Durchsatz an Requests hast und/oder eine gewisse Echtzeitbedingung hast.

"Frontend" war in meinem Fall auch Java (Android). Da habe ich sowohl die Möglichkeit für synchrone als auch asynchrone Requests implementiert. Im Asynchronen Fall hat die Methode zum starten des Requests einen Callback übergeben bekommen. Intern habe ich dann -wie schon gesagt- anhand von UUIDs die Request/Responses gemapped. Und bei synchronen einfach den Request gestartet, den Thread so lange blockiert bis der Response da war und diesen dann zurückgegeben.
Das ganze werde ich noch ausbauen, sodass im Falle einer nicht vorhandenen WebSocket Verbindung die Kommunikation alternativ über HTTP ablaufen kann (Server muss dazu natürlich entsprechend auch vorbereitet werden).