Websocket-API als Ersatz für die REST-API?

Ich habe eine Anwendung, deren Hauptfunktion in Echtzeit über Websockets oder lange Abfragen funktioniert.

Der größte Teil der Website ist jedoch in RESTful-Form geschrieben, was für Anwendungen und andere Kunden in Zukunft von Vorteil ist. Ich denke jedoch darüber nach, für alle Site-Funktionen von REST auf eine Websocket-API umzusteigen. Das würde es mir leichter machen, Echtzeitfunktionen in alle Teile der Site zu integrieren. Würde dies das Erstellen von Anwendungen oder mobilen Clients erschweren?

Ich habe festgestellt, dass einige Leute bereits solche Sachen machen: SocketStream

Um nicht zu sagen, dass die anderen Antworten hier keinen Wert haben, machen sie einige gute Punkte. Aber ich werde gegen den allgemeinen Konsens verstoßen und Ihnen zustimmen, dass die Umstellung auf Websockets für mehr als nur Echtzeitfunktionen sehr attraktiv ist.

Ich denke ernsthaft darüber nach, meine App über Websockets von einer RESTful-Architektur auf einen RPC-Stil umzustellen. Dies ist keine "Spielzeug-App", und ich spreche nicht nur über Echtzeitfunktionen, daher habe ich Reservierungen. Aber ich sehe viele Vorteile in diesem Weg und denke, dass es sich als außergewöhnliche Lösung herausstellen könnte.

Mein Plan ist es, DNode , SocketIO und Backbone zu verwenden . Mit diesen Tools können meine Backbone-Modelle und -Sammlungen durch einfaches Aufrufen einer Funktion im RPC-Stil von / an Client und Server weitergegeben werden. Sie müssen keine REST-Endpunkte mehr verwalten, Objekte serialisieren / deserialisieren usw. Ich habe noch nicht mit Socketstream gearbeitet, aber es lohnt sich, es sich anzusehen.

Ich habe noch einen langen Weg vor mir, bevor ich definitiv sagen kann, dass dies eine gute Lösung ist, und ich bin sicher, dass es nicht für jede Anwendung die beste Lösung ist, aber ich bin überzeugt, dass diese Kombination außergewöhnlich leistungsfähig wäre. Ich gebe zu, dass es einige Nachteile gibt, wie den Verlust der Fähigkeit, Ressourcen zwischenzuspeichern. Aber ich habe das Gefühl, dass die Vorteile sie überwiegen werden.

Ich würde gerne Ihre Fortschritte bei der Erforschung dieser Art von Lösung verfolgen. Wenn Sie irgendwelche Github-Experimente haben, weisen Sie mich bitte darauf hin. Ich habe noch keine, hoffe aber bald.

Unten finden Sie eine Liste der später zu lesenden Links, die ich gesammelt habe. Ich kann nicht dafür bürgen, dass sie sich alle lohnen, da ich nur viele von ihnen überflogen habe. Aber hoffentlich helfen einige.

Tolles Tutorial zur Verwendung von Socket.IO mit Express. Es stellt Express-Sitzungen für socket.io bereit und erläutert, wie für jeden authentifizierten Benutzer unterschiedliche Räume eingerichtet werden können.

• http://www.danielbaulig.de/socket-ioexpress/

Tutorial zu node.js / socket.io / backbone.js / express / connect / jade / redis mit Authentifizierung, Joyent-Hosting usw.:

• http://fzysqr.com/2011/02/28/nodechat-js-using-node-js-backbone-js-socket-io-and-redis-to-make-a-real-time-chat-app/
• http://fzysqr.com/2011/03/27/nodechat-js-continued-authentication-profiles-ponies-and-a-meaner-socket-io/

Tutorial zur Verwendung von Pusher mit Backbone.js (mit Rails):

• http://blog.pusher.com/2011/6/21/backbone-js-now-realtime-with-pusher

Erstellen Sie eine Anwendung mit backbone.js auf dem Client und node.js mit express, socket.io, dnode auf dem Server.

• http://andyet.net/blog/2011/feb/15/re-using-backbonejs-models-on-the-server-with-node/
• http://addyosmani.com/blog/building-spas-jquerys-best-friends/
• http://fzysqr.com/2011/02/28/nodechat-js-using-node-js-backbone-js-socket-io-and-redis-to-make-a-real-time-chat-app/
• http://fzysqr.com/2011/03/27/nodechat-js-continued-authentication-profiles-ponies-and-a-meaner-socket-io/

Backbone mit DNode verwenden:

• http://quickleft.com/blog/backbone-without-ajax-part-ii
• http://quickleft.com/blog/backbone-without-ajax-part-1
• http://sorensen.posterous.com/introducing-backbone-redis
• https://github.com/cowboyrushforth/minespotter
• http://amir.unoc.net/how-to-share-backbonejs-models-with-nodejs
• http://hackerne.ws/item?id=2222935
• http://substack.net/posts/24ab8c

HTTP REST und WebSockets sind sehr unterschiedlich. HTTP ist zustandslos , sodass der Webserver nichts wissen muss und das Caching im Webbrowser und in Proxys erfolgt. Wenn Sie WebSockets verwenden, wird Ihr Server statusbehaftet und Sie müssen eine Verbindung zum Client auf dem Server haben.

Request-Reply-Kommunikation vs Push

Verwenden Sie WebSockets nur, wenn Sie Daten vom Server zum Client übertragen müssen. Dieses Kommunikationsmuster ist in HTTP nicht enthalten (nur durch Problemumgehungen). PUSH ist hilfreich, wenn Ereignisse, die von anderen Clients erstellt wurden, anderen verbundenen Clients zur Verfügung stehen müssen, z. B. in Spielen, in denen Benutzer auf das Verhalten anderer Clients reagieren sollten. Oder wenn Ihre Website etwas überwacht, bei dem der Server ständig Daten an den Client sendet, z. B. Aktienmärkte (live).

Wenn Sie keine Daten vom Server pushen müssen, ist es normalerweise einfacher, einen zustandslosen HTTP-REST-Server zu verwenden. HTTP verwendet ein einfaches Request-Reply- Kommunikationsmuster.

Ich denke über den Übergang zu einer WebSocket-API für alle Site-Funktionen nach

Nein, du solltest es nicht tun. Es schadet nichts, wenn Sie beide Modelle unterstützen. Verwenden Sie REST für die Einwegkommunikation / einfache Anforderungen und WebSocket für die Zweiwegkommunikation , insbesondere wenn der Server eine Echtzeitbenachrichtigung senden möchte.

WebSocket ist ein effizienteres Protokoll als RESTful HTTP, aber in den folgenden Bereichen werden RESTful HTTP- Scores über WebSocket erzielt.

1. Ressourcen zum Erstellen / Aktualisieren / Löschen wurden für HTTP gut definiert. Sie müssen diese Vorgänge für WebSockets auf niedriger Ebene implementieren.

2. WebSocket-Verbindungen werden vertikal auf einem einzelnen Server skaliert, während HTTP-Verbindungen horizontal skaliert werden. Es gibt einige proprietäre, nicht auf Standards basierende Lösungen für die horizontale Skalierung von WebSocket.

3. HTTP bietet viele gute Funktionen wie Caching, Routing, Multiplexing, Gzipping usw. Diese müssen auf Websocket aufbauen, wenn Sie sich für Websocket entscheiden.

4. Suchmaschinenoptimierungen funktionieren gut für HTTP-URLs.

5. Alle Proxy-, DNS- und Firewalls kennen den WebSocket-Verkehr noch nicht vollständig. Sie erlauben Port 80, können jedoch den Datenverkehr einschränken, indem sie zuerst darauf herumschnüffeln.

6. Sicherheit mit WebSocket ist alles oder nichts.

Weitere Informationen finden Sie in diesem Artikel .

Das einzige Problem, das ich mit TCP (WebSockets) als Hauptstrategie für die Bereitstellung von Webinhalten lösen kann, besteht darin, dass es nur sehr wenig Lesematerial zum Entwerfen Ihrer Website-Architektur und -Infrastruktur mit TCP gibt.

Sie können also nicht aus den Fehlern anderer lernen und die Entwicklung wird langsamer. Es ist auch keine "bewährte" Strategie.

Natürlich verlieren Sie auch alle Vorteile von HTTP (Statuslosigkeit und Caching sind die größeren Vorteile).

Denken Sie daran, dass HTTP eine Abstraktion für TCP ist, die zum Bereitstellen von Webinhalten entwickelt wurde.

Und vergessen wir nicht, dass SEO und Suchmaschinen keine Websockets betreiben. So können Sie SEO vergessen.

Persönlich würde ich dagegen empfehlen, da es zu viel Risiko gibt.

Verwenden Sie WS nicht zum Bereitstellen von Websites, sondern zum Bereitstellen von Webanwendungen

Wenn Sie jedoch auf jeden Fall ein Spielzeug oder eine persönliche Website haben , entscheiden Sie sich dafür. Probieren Sie es aus, seien Sie auf dem neuesten Stand. Für ein Unternehmen oder eine Firma können Sie das Risiko dafür nicht rechtfertigen.

Ich habe eine kleine Lektion gelernt (auf die harte Tour). Ich habe eine Anwendung zum Knacken von Zahlen erstellt, die auf Ubuntu AWS EC2-Clouddiensten ausgeführt wird (verwendet leistungsstarke GPUs), und ich wollte ein Front-End dafür erstellen, um den Fortschritt in Echtzeit zu verfolgen. Aufgrund der Tatsache, dass es Echtzeitdaten benötigte, war es offensichtlich, dass ich Websockets benötigte, um die Updates zu pushen.

Es begann mit einem Proof of Concept und funktionierte hervorragend. Als wir es dann der Öffentlichkeit zugänglich machen wollten, mussten wir eine Benutzersitzung hinzufügen, sodass wir Anmeldefunktionen benötigten. Unabhängig davon, wie Sie es betrachten, muss der Websocket wissen, mit welchem ​​Benutzer er sich befasst. Daher haben wir die Verknüpfung verwendet, die Websockets zur Authentifizierung der Benutzer zu verwenden . Es schien offensichtlich und es war bequem.

Wir mussten tatsächlich einige Zeit ruhig verbringen, um die Verbindungen zuverlässig zu machen. Wir haben mit einigen billigen Websocket-Tutorials begonnen, aber festgestellt, dass unsere Implementierung nicht automatisch wieder eine Verbindung herstellen konnte, wenn die Verbindung unterbrochen wurde. Das alles hat sich verbessert, als wir auf Socket-Io umgestiegen sind. Socket-io ist ein Muss!

Um ehrlich zu sein, haben wir einige großartige Socket-Io-Funktionen verpasst. Socket-io hat noch viel mehr zu bieten, und ich bin sicher, wenn Sie es bei Ihrem ursprünglichen Entwurf berücksichtigen, können Sie mehr daraus machen. Im Gegensatz dazu haben wir gerade die alten Websockets durch die Websocket-Funktionalität von Socket-Io ersetzt, und das war es. (keine Räume, keine Kanäle, ...) Eine Neugestaltung hätte alles leistungsfähiger machen können. Dafür hatten wir aber keine Zeit. Das ist etwas, an das wir uns bei unserem nächsten Projekt erinnern sollten.

Als nächstes haben wir begonnen , immer mehr Daten zu speichern (Benutzerhistorie, Rechnungen, Transaktionen, ...). Wir haben alles in einer AWS-Dynamodb-Datenbank gespeichert und WIEDER haben wir Socket-Io verwendet, um die CRUD-Operationen vom Front-End zum Back-End zu kommunizieren. Ich denke, wir sind dort falsch abgebogen. Es war ein Fehler.

• Denn kurz nachdem wir herausgefunden hatten, dass die Cloud-Services (AWS) von Amazon einige großartige Tools für den Lastenausgleich / die Skalierung für RESTful-Anwendungen bieten .
• Wir haben jetzt den Eindruck, dass wir viel Code schreiben müssen, um die Handshakes der CRUD-Operationen auszuführen .
• Kürzlich haben wir die Paypal-Integration implementiert. Wir haben es geschafft, es zum Laufen zu bringen. Aber auch hier machen es alle Tutorials mit RESTful-APIs . Wir mussten ihre Beispiele umschreiben / überdenken, um sie mit Websockets zu implementieren. Wir haben es aber ziemlich schnell zum Laufen gebracht. Aber es fühlt sich so an, als würden wir gegen den Strom gehen.

Nachdem wir das alles gesagt haben, werden wir nächste Woche live gehen. Wir sind rechtzeitig dort angekommen, alles funktioniert. Und es ist schnell, aber wird es skalieren?

Ich würde in Betracht ziehen, beide zu verwenden . Jede Technologie hat ihre Vorzüge und es gibt keine Einheitslösung.

Die Arbeitstrennung geht so:

1. WebSockets sind die primäre Methode einer Anwendung zur Kommunikation mit dem Server, auf dem eine Sitzung erforderlich ist. Dies eliminiert viele Hacks, die für die älteren Browser benötigt werden (das Problem ist die Unterstützung für die älteren Browser, wodurch dies beseitigt wird).

2. Die RESTful-API wird für GET-Aufrufe verwendet, die nicht sitzungsorientiert sind (dh keine Authentifizierung erforderlich sind) und vom Browser-Caching profitieren. Ein gutes Beispiel hierfür wären Referenzdaten für Dropdowns, die von einer Webanwendung verwendet werden. Jedoch. kann sich etwas öfter ändern als ...

3. HTML und Javascript. Diese umfassen die Benutzeroberfläche der Webanwendung. Diese würden im Allgemeinen davon profitieren, auf einem CDN platziert zu werden.

4. Webdienste, die WSDL verwenden, sind immer noch der beste Weg Kommunikation auf Unternehmensebene und zwischen Unternehmen, da sie einen genau definierten Standard für die Weitergabe von Nachrichten und Daten bieten. In erster Linie würden Sie dies auf ein Datapower-Gerät auslagern, um einen Proxy für Ihren Webdienst-Handler zu erstellen.

All dies geschieht über das HTTP-Protokoll, das bereits sichere Sockets über SSL verwendet.

Für die mobile Anwendung können Websockets jedoch keine Verbindung zu einer getrennten Sitzung herstellen ( So stellen Sie nach dem Schließen der Verbindung wieder eine Verbindung zum Websocket her ), und die Verwaltung ist nicht trivial. Also für mobile Anwendungen , würde ich immer noch REST API empfehlen und Polling.

Eine andere Sache, auf die Sie bei der Verwendung von WebSockets vs REST achten sollten, ist die Skalierbarkeit . WebSocket-Sitzungen werden weiterhin vom Server verwaltet. RESTful APIs sind bei ordnungsgemäßer Ausführung zustandslos (was bedeutet, dass kein Serverstatus verwaltet werden muss), sodass die Skalierbarkeit horizontal (was billiger ist) als vertikal zunehmen kann .

Möchte ich Updates vom Server?

• Ja: Socket.io
• Keine Pause

Die Nachteile von Socket.io sind:

• Skalierbarkeit: WebSockets erfordern offene Verbindungen und ein ganz anderes Ops-Setup als die Web-Skalierung.
• Lernen: Ich habe keine unbegrenzte Zeit für mein Lernen. Dinge müssen erledigt werden!

Ich werde Socket.io weiterhin in meinem Projekt verwenden, aber nicht für grundlegende Webformulare, die REST gut macht.

Auf WebSockets (oder langen Abfragen) basierende Transporte dienen hauptsächlich der (nahezu) Echtzeitkommunikation zwischen Server und Client. Obwohl es zahlreiche Szenarien gibt, in denen solche Transporte erforderlich sind, z. B. Chat oder Echtzeit-Feeds oder andere Dinge, müssen nicht alle Teile einer Webanwendung unbedingt bidirektional mit dem Server verbunden sein.

REST ist eine ressourcenbasierte Architektur, die gut verstanden wird und ihre eigenen Vorteile gegenüber anderen Architekturen bietet. WebSockets tendieren eher zu Datenströmen / Feeds in Echtzeit, bei denen Sie eine Art serverbasierte Logik erstellen müssen, um Ressourcen und Feeds zu priorisieren oder zu unterscheiden (falls Sie REST nicht verwenden möchten).

Ich gehe davon aus, dass es in Zukunft möglicherweise mehr WebSockets-zentrierte Frameworks wie Socketstream geben wird, wenn dieser Transport weiter verbreitet und in Form von Datentyp / formunabhängiger Zustellung besser verstanden / dokumentiert wird. Ich denke jedoch, dass dies nicht bedeutet, dass es den REST ersetzen würde / sollte, nur weil es Funktionen bietet, die in zahlreichen Anwendungsfällen und Szenarien nicht unbedingt erforderlich sind.

Das ist keine gute Idee. Der Standard ist noch nicht einmal fertiggestellt, die Unterstützung variiert je nach Browser usw. Wenn Sie dies jetzt tun möchten, müssen Sie auf Flash oder lange Abfragen usw. zurückgreifen. In Zukunft wird es wahrscheinlich immer noch keine geben Sehr sinnvoll, da der Server es unterstützen muss, Verbindungen für jeden einzelnen Benutzer offen zu lassen. Die meisten Webserver sind stattdessen so konzipiert, dass sie schnell auf Anfragen reagieren und diese so schnell wie möglich schließen können. Selbst Ihr Betriebssystem müsste optimiert werden, um mit einer hohen Anzahl gleichzeitiger Verbindungen fertig zu werden (jede Verbindung verbraucht mehr kurzlebige Ports und Speicher). Halten Sie sich an REST für so viele Bereiche der Website wie möglich.