it-swarm.com.de

Ist die Leistung der einzige Grund, SignalR (Websockets) nicht vollständig anstelle einer herkömmlichen REST API) zu verwenden?

Ich habe SignalR verwendet, um in mehreren meiner Projekte Echtzeit-Messaging-Funktionen zu erreichen. Es scheint zuverlässig zu funktionieren und ist sehr einfach zu erlernen.

Zumindest für mich besteht die Versuchung darin, die Entwicklung eines Web-API-Dienstes aufzugeben und SignalR für alles zu verwenden.

Ich bin der Meinung, dass dies durch durchdachtes Design erreicht werden könnte, und wenn dies der Fall wäre, würde dies bedeuten, dass weitaus weniger Client-Code erforderlich wäre. Noch wichtiger wäre, dass es eher eine einzige Schnittstelle zu Diensten als eine geteilte Schnittstelle geben würde, und im schlimmsten Fall könnte man dies verkabeln, ohne darüber nachzudenken, wann Dinge gerendert werden usw.

Also würde ich gerne wissen:

  1. Gibt es einen anderen Grund, SignalR nicht anstelle aller Webdienste außer der Leistung zu verwenden?
  2. Ist die Leistung von SignalR ausreichend, um dies nicht sinnvoll zu machen?

Es war lange ein Traum von mir, serverseitige Objekt- und Dienstdefinitionen in clientseitigen Dienstzugriffscode übersetzen zu können, ohne etwas Dummes wie node.js. Wenn ich zum Beispiel ein interessantes Objekt InterestingObject und einen Dienst für CRUD das Objekt InterestingObjectService definiere, kann ich eine Standard-URL-Route zum Dienst definieren - sagen wir "/ { serviceName}/{methodName} "- aber ich muss noch Client-Code schreiben, um auf den Service zuzugreifen. Da das Objekt vom Client zum Server und zurück übergeben wird, gibt es keinen praktischen Grund, have das Objekt explizit im clientseitigen Code zu definieren, und es sollte auch nicht erforderlich sein, das Objekt explizit zu definieren Routen zur Durchführung von CRUD-Operationen. Ich bin der Meinung, dass es eine Möglichkeit geben sollte, all dies zu standardisieren, damit es möglich ist, einen Client unter der Annahme zu schreiben, dass der Dienstzugriff vom Client zum Server und zurück so transparent funktioniert, wie wenn ich WinForms oder = schreiben würde Java Applet oder Native App oder was hast du?.

Wenn SignalR gut genug ist, um es anstelle eines herkömmlichen Webdienstes zu verwenden, kann dies eine praktikable Möglichkeit sein, dies zu erreichen. SignalR enthält bereits Funktionen, mit denen der Hub wie der von mir beschriebene Dienst funktioniert, sodass ich einen CRUD-Dienst (Common Base) definieren kann, der all diese Funktionen mit einigen Überlegungen sofort einsatzbereit bietet. Dann könnte ich den Servicezugriff fast als selbstverständlich betrachten, was mir den Ärger erspart, Code neu zu schreiben, um auf etwas zuzugreifen, auf das gemäß Konvention zugegriffen werden kann - und vor allem die Zeit, die ich für das Schreiben von Code aufwenden müsste, um zu definieren, wie dieser aktualisiert wird das DOM.

Nachdem ich meine Bearbeitung gelesen habe, denke ich, dass es ein wenig unsinnig sein kann. Bitte zögern Sie nicht, mich zu fragen, wenn Sie Fragen zu dem haben, worauf ich mich einlasse. Grundsätzlich möchte ich, dass der Servicezugriff so transparent wie möglich ist.

44

Diese beiden Technologien haben einen sehr unterschiedlichen Zweck.

  • REST ist für gewöhnliche Aufrufe einer API wobei der Client ein aktiver Akteur ist der Vermittlungsstelle. Wenn der Client GPS-Koordinaten einer Adresse finden muss, initiiert der Client den Aufruf der API und wartet, bis er die Koordinaten empfängt, oder es tritt ein Fehler auf oder es vergeht eine Zeitüberschreitung.

  • Web-Sockets sind für alles gedacht, was anders gemacht werden muss. Wenn ich beispielsweise eine Intranet-Website verwende, die mir in Echtzeit die Protokolle und die Leistung verschiedener Server anzeigt, der Client ist möglicherweise passiv und warte, bis der Server ihm eine neu veröffentlichte Protokollnachricht oder Leistung sendet Metriken.

Der Unterschied ist klar: Im ersten Fall entscheidet der Kunde, wann er eine bestimmte Information benötigt; Im zweiten Fall wartet der Kunde einfach darauf, kontaktiert zu werden, und weiß möglicherweise nicht, wann dies der Fall sein wird.

In gewisser Weise sind beide austauschbar: Sie können Web-Sockets implementieren, wenn Sie sie nicht benötigen (dh der Client ruft den Server über Web-Sockets auf, anstatt einen REST -Aufruf) durchzuführen, und Sie können Verwenden Sie Polling oder Long Polling als Ersatz für Web-Sockets (da dies jahrelang erfolgreich verwendet wurde, bis Web-Sockets so populär wurden).

Ihre Austauschbarkeit ist jedoch mit Kosten verbunden:

  • Wenn Sie anstelle von Web-Sockets Abfragen oder lange Abfragen verwenden, verschwenden Sie häufig Bandbreite.

  • Wenn Sie Web-Sockets verwenden, um das zu tun, was über die Web-API möglich ist, behalten Sie alle Verbindungen aller aktiven Clients geöffnet, was möglicherweise nicht das ist, was Sie wirklich wollen. Für eine kleine Website, auf der Sie höchstens 5 Kunden gleichzeitig erwarten, ist dies kein Problem. Für einen Dienst wie Amazon AWS wäre dies technisch nicht einfach zu lösen.

Verwenden Sie keine Web-Sockets, wenn Sie sie nicht benötigen. Um GPS-Koordinaten einer Adresse zu erhalten, erhalte ich nichts, wenn ich eine Web-Sockets-Verbindung öffne, einen Anruf tätige, auf eine Antwort warte und die Verbindung schließe: REST erfüllt meine Anforderungen für solche Szenarien.

  • Wenn Sie wiederholt und häufig über einen REST -Aufruf an einen Dienst) nach Informationen suchen, kann dies ein gutes Zeichen dafür sein, dass Sie zu Web-Sockets wechseln sollten. In ähnlicher Weise reduziert Stack Overflow die Bandbreitennutzung durch Verwendung Web-Sockets, da dies dazu beiträgt, dass Benutzer ihre Zeit nicht damit verbringen, F5 auf der Startseite zu drücken, um festzustellen, ob sie neue Nachrichten haben.

  • Wenn Sie feststellen, dass Sie Web-Sockets-Verbindungen öffnen, einen einzelnen Anruf tätigen und diese dann schließen, oder wenn Ihre Verbindungen geöffnet bleiben, der Server jedoch nur auf Kundenanforderung etwas an den Client sendet, wechseln Sie zu REST.

Außerdem haben Web-Sockets immer noch ein eingeschränkte Unterstützung und sind nicht immer einfach zu implementieren. Während SignalR die Implementierung vereinfacht, bedeutet dies nicht, dass Sie keine Schwierigkeiten haben, es in anderen Sprachen/Kontexten/Umgebungen zu implementieren. Mit REST ist das ganz einfach: Es kann sich um einen curl -Aufruf oder eine ähnliche Funktion handeln, die in jeder Mainstream-Sprache verfügbar ist. Bei Web-Sockets können Sie nicht sicher sein, wie lange es dauern würde, einen Client mit [Geben Sie hier den Namen einer Sprache ein, die Sie noch nicht kennen] ein.

Ich habe Web-Sockets in mehreren Projekten in .NET verwendet, Python und node.js.

  • In .NET war es nicht allzu schwierig, aber ich habe immer noch ein paar Tage damit verbracht, einige kryptische Probleme herauszufinden, z. B. die Verbindung zu trennen, sobald sie geöffnet wird. (Dies war vor SignalR; ich habe SignalR nie ausprobiert). Ich habe WCF auch im Web-Sockets-Modus verwendet, was auch nicht ohne Probleme war (aber ich glaube, dass WCF immer mit Problemen verbunden ist).

  • In node.js war dies machbar, aber ich musste zweimal die Bibliotheken wechseln, bis ich eine gefunden habe, die funktioniert. Ich glaube, ich habe mindestens eine Woche damit verbracht, Web-Sockets zu erstellen. Hello World.

  • In Python habe ich es einmal versucht, zwei oder drei Tage verbracht und aufgegeben. Es hat nie funktioniert.

Vergleichen Sie dies mit REST: Das einzige Problem, das bei einer neuen Sprache/einem neuen Framework auftreten kann, besteht darin, zu wissen, wie man POST Dateien oder eine sehr große binäre Antwort erhält). Ich erinnere mich, dass ich einige Stunden damit verbracht habe, nach Lösungen zu suchen Für einige Sprachen sind ein paar Stunden für einen Sonderfall nichts im Vergleich zu Tagen oder Wochen für eine einfache Hello World.

51

Nur meine 2 Cent ...

Ich denke, es geht nicht wirklich um Leistung oder was auch immer. Es geht um Standards. REST ist ein Standard und IMHO hat folgende Vorteile:

  • HTTP-Anforderungen sind einfach zu verwenden. Jeder kann schnell eine REST API. Heck, Sie können sogar den Browser öffnen und eine URL eingeben, um die Daten zu sehen, wie interaktiver können Sie sein?
  • (Fast) jede Programmiersprache kann es verwenden. Es ist eine Art universelle Schnittstelle. Die Schnittstelle zu SignalR aus einer exotischen Sprache scheint weniger offensichtlich.
  • Es hat nette Werkzeugunterstützung, wie http://petstore.swagger.wordnik.com/
  • Es ist eine schöne "Schnittstelle" zum Debuggen. Sie können eingehende und ausgehende Nachrichten einfach direkt im Browser überwachen, die Daten anzeigen usw. Bei Websockets und benutzerdefinierten Bibliotheken ist es nicht so offensichtlich, dass Sie alles explizit protokollieren müssen.
1
dagnelies