Warum wird in Webanwendungen häufig REST anstelle von RPC-ähnlichen Mechanismen verwendet?

Ich habe vor kurzem bei einem Unternehmen angefangen, das ein ziemlich ungewöhnliches benutzerdefiniertes Framework für seine Webanwendungen verwendet, zumindest im Vergleich zu den mir bekannten typischen Webanwendungs-Frameworks. Anstelle eines RESTful-Webservices wird ein RPC-Mechanismus zur Kommunikation mit dem Server verwendet.

Die Kommunikation mit dem Server sieht aus wie ein einfacher Funktionsaufruf, die Funktion wird jedoch auf dem Server und nicht auf dem Client ausgeführt. Auf der Serverseite kann definiert werden, welche Funktionen der Client aufrufen kann. Die Details, wie dies in http-Anforderungen übersetzt wird, werden vollständig weg abstrahiert.

Ich habe dies jetzt nur eine kurze Zeit verwendet, aber es scheint ziemlich praktisch zu sein. Aber ich frage mich, welche Nachteile dieses Ansatzes mir fehlen. Alle anderen scheinen es anders zu machen, was normalerweise ein Zeichen für mich ist, dass ich vielleicht etwas Dummes oder Geniales mache, mit viel höheren Chancen für Ersteres.

REST wurde für das Web entwickelt, und das Web wurde für REST entwickelt. Die beiden passen einfach zusammen. Roy Fieldings Doktorarbeit aus dem Jahr 2000 über Architekturstile und den Entwurf netzwerkbasierter Softwarearchitekturen definierte und führte den Begriff REST ein , und es besteht ein erhebliches Zusammenspiel zwischen dem Web und REST: Roy Fielding arbeitete an HTTP / 1.1, dessen Hauptautor er ist. und er verwendete, was er dort lernte, um REST in seiner Dissertation zu beschreiben.

Der einfache Grund, warum das Web und REST so gut zusammenpassen, ist, dass die Definition von REST aus der Funktionsweise des Webs extrahiert wurde und das Web eine Implementierung von REST ist.

Aus diesem Grund eignet sich REST gut für Webservices und Web-Apps: Sie tun einfach die gleichen Dinge, von denen bereits nachgewiesen wurde, dass sie im "menschlichen" Web funktionieren, und wenden sie auf das "maschinelle" Web an.

Das große Problem mit RPC (abhängig von der genauen Implementierung) liegt im Wesentlichen in den Irrtümern des Distributed Computing , die in diesem Whitepaper von Arnon Rotem-Gal-Oz näher erläutert werden :

1. Das Netzwerk ist zuverlässig
2. Die Latenz ist Null
3. Die Bandbreite ist unendlich
4. Das Netzwerk ist sicher
5. Die Topologie ändert sich nicht
6. Es gibt einen Administrator
7. Die Transportkosten betragen null
8. Das Netzwerk ist homogen

Dies sind alles Annahmen, die Neulinge normalerweise treffen, wenn sie damit beginnen, verteilte Systeme zu erstellen. Natürlich sind alle falsch. Und Sie müssen alle berücksichtigen, wenn Sie verteilte Systeme erstellen.

Das Problem bei vielen RPC-Implementierungen besteht darin, dass Remoteaufrufe wie lokale Aufrufe aussehen. Aber sie sind nichts gleich:

• Ein Ortsgespräch scheitert nie. Die von Ihnen aufgerufene Unterroutine schlägt möglicherweise fehl, der Aufruf selbst jedoch nie. Ein Remote-Aufruf kann im Netzwerk verloren gehen
• Ein Ortsgespräch wird sofort geführt. Die von Ihnen aufgerufene Unterroutine kann lange ausgeführt werden (oder sogar für immer, wenn sie in einer Endlosschleife hängen bleibt), aber der Aufruf selbst benötigt überhaupt keine Zeit (naja, höchstens eine Handvoll CPU-Anweisungen, wenn der Aufruf aktiv ist) eingeblendet, aber es ist sehr schnell) - ein Fernanruf kann für eine lange Zeit im Netzwerk hängen bleiben
• Wenn die Subroutine normal zurückkehrt, kommt das Ergebnis immer zurück - bei einem Fernaufruf kann das Ergebnis im Netzwerk verloren gehen
• Die Rückkehr erfolgt sofort - entfernte Ergebnisse können lange Zeit im Netzwerk übertragen werden
• Wenn ich eine Subroutine einmal aufrufe, wird sie genau einmal ausgeführt - ein Remote-Aufruf kann im Netzwerk verloren gehen oder dupliziert werden, sodass die Remote-Routine zwischen 0 und beliebig oft ausgeführt werden kann
• Ich erhalte genau ein Ergebnis zurück - ein entferntes Ergebnis kann verloren gehen oder dupliziert werden, sodass Sie das Ergebnis möglicherweise 0-mal oder öfter erhalten
• Wenn ich ein Unterprogramm zweimal aufrufe, erhalte ich zwei Ergebnisse und das Ergebnis des ersten Aufrufs vor dem Ergebnis des zweiten Aufrufs - Sie können es wahrscheinlich schon erraten: Mit RPC erhalten Sie möglicherweise keine Ergebnisse oder nur das erste zurück oder nur die zweite oder die zweite vor der ersten oder die erste kann verloren gehen und Sie erhalten die zweite zweimal oder umgekehrt, und so weiter ...
• Wenn ich aund dann banrufe, erhalte ich das Ergebnis von aund dann das Ergebnis von b - dies ist nur eine allgemeinere Version des vorherigen Punkts. Mit RPC können Sie eine der beiden Antworten 0 oder mehrmals in beliebiger Reihenfolge erhalten

Sie werden mit allen oben genannten für einen Remote - Aufruf zu tun haben. Wenn Ihr Framework Remoteaufrufe nicht von lokalen Aufrufen unterscheidet, können Sie dies nicht tun, da Sie nicht wissen, welche Remoteaufrufe dies sind. Das Framework kann versuchen, all diese für Sie zu erledigen, aber das Problem ist: Das Framework weiß nicht so viel über Ihr System wie Sie. Es weiß nicht, ob es Anrufe gibt, bei denen es eigentlich egal ist, ob man sich ab und zu verirrt. Das Framework muss also sehr defensiv sein, und das ist in Bezug auf Latenz und Bandbreite teuer.

Zumal das Framework Sie eigentlich nicht abschirmen kann. Das CAP-Theorem besagt, dass ein verteiltes System nicht gleichzeitig konsistent, verfügbar und partitionstolerant sein kann. Genauer gesagt heißt es, dass das System nach dem Auftreten einer Partition nicht mehr gleichzeitig konsistent und verfügbar sein kann, sondern nur noch eine auswählen muss (entgegen der landläufigen Meinung besagt das Theorem nicht, dass Sie nicht alle drei haben können, wenn das System ausgeführt wird normalerweise Sie können alle drei haben, aber wenn Sie eine Partition haben, haben Sie eine der beiden anderen) zu wählen. Das PACELC-Theorem erweitert das CAP-Theorem, indem es zeigt, dass Sie selbst bei laufendem System die Latenz gegenüber der Konsistenz austauschen müssen.

Dies sind wichtige Kompromisse, vor denen das Framework Sie so gut wie nicht schützen kann, da sie domänenspezifisch und für das Kerndesign wichtig sind.

Vergleichen Sie dies mit einem Ansatz wie dem von Erlang, der funktioniert : In Erlang werden alle Nachrichtensendungen als remote behandelt, auch wenn sie lokal sind. Dies bedeutet, dass Sie immer bereit sind, alle oben genannten Probleme (und viele weitere) zu lösen. Bei lokalen Prozessen ist dies jedoch mit einem gewissen Aufwand verbunden. Um dies zu unterstützen, gibt es eine Vielzahl von Tools, Frameworks, Bibliotheken, Mustern und Redewendungen für die Fehlerbehandlung und -überwachung.

Sie haben nicht beschrieben, wie Ihr RPC-Framework im Besonderen funktioniert und welche Sprache oder Bibliotheken Sie verwenden, aber ich habe den starken Verdacht, dass es zum früheren Typ "so tun, als ob das Netzwerk nicht existiert" gehört. Die funktionieren einfach nicht. Es ist in Ordnung , die Unterscheidung zwischen lokalen und Remote-Anrufen zu entfernen, indem alles als Remote- Anruf behandelt wird. Tut es andersrum Abstracts zu viel: Das Netzwerk ist Teil des Systems, wenn man es abstrakt, Sie abstrahieren etwas , dass Sie tatsächlich weg müssen wissen , über.

Ob Sie nun speziell REST verwenden müssen oder nicht, das ist eine ganz andere Frage. Wie ich oben erläutert, wurde die Bahn für REST und REST wurde entwickelt für das Web entwickelt, so dass die beiden tun zusammen Sinn machen, aber können Sie andere Baustile verwenden, wenn Sie möchten. Zumindest ein Teil Ihrer Frage betraf das Thema "Warum nicht RPC?". Ich habe die oben genannten Gründe dargelegt und genauer erklärt, warum die Art von RPC, von der ich vermute, dass Sie sie verwenden, Sie in Schwierigkeiten bringen kann.

Es gibt bereits einige gute Ideen in den Kommentaren, die ich hier wiederholen werde:

1. RPC ist normalerweise technologie-spezifisch.
2. Was Entwickler am meisten interessiert, ist JSON, nicht REST.

JSON hat einige sehr schöne Eigenschaften. Es ist einfach, für einen Menschen leicht zu lesen, für einen Computer leicht zu analysieren, und Javascript erkennt es sofort nativ (es ist, wie Sie wissen, Javascript- ).

Wenn Sie auf Einschränkungen wie REST verzichten möchten, können Sie mit JSON fast alles tun, einschließlich Remoteprozeduraufrufen. Sie müssen lediglich ein geeignetes Protokoll erstellen. Tatsächlich existiert ein solches Protokoll bereits: JSON-RPC.

--> {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}
<-- {"jsonrpc": "2.0", "result": 19, "id": 1}

RPC und REST sind nur unterschiedliche Ansätze mit Vor- und Nachteilen und sind je nach Kontext von Wert. REST wird am besten für die Arbeit mit den Ressourcen beschrieben, wobei sich RPC mehr auf die Aktionen bezieht. RPC-Clients sind auf verschiedene Weise eng mit der Service-Implementierung verbunden, und es wird sehr schwierig, die Service-Implementierung zu ändern, ohne die Clients zu beschädigen.