Was ist der Unterschied zwischen RPC und REST?
Remote Procedure Call (RPC) und REST sind zwei Architekturstile im API-Design. APIs sind Mechanismen, die es zwei Software-Komponenten ermöglichen, über eine Reihe von Definitionen und Protokollen miteinander zu kommunizieren. Um Funktionen auszuführen, verwenden Softwareentwickler zuvor entwickelte Komponenten oder Komponenten von Drittanbietern, sodass sie nicht alles von Grund auf neu schreiben müssen. Mit RPC APIs können Entwickler Remote-Funktionen auf externen Servern so aufrufen, als ob sie in ihrer Software lokal vorhanden wären. Sie können Ihrer Anwendung beispielsweise Chat-Funktionen hinzufügen, indem Sie remote Messaging-Funktionen einer anderen Chat-Anwendung aufrufen. Im Gegensatz dazu können Sie mit REST-APIs bestimmte Datenoperationen auf einem Remote-Server ausführen. Mithilfe von REST-APIs könnte Ihre Anwendung beispielsweise Mitarbeiterdaten auf einem Remote-Server einfügen oder ändern.
Was sind die Ähnlichkeiten zwischen RPC und REST?
Remote Procedure Call (RPC) und REST sind beides Methoden zur Entwicklung von APIs. APIs sind im modernen Webdesign und anderen verteilten Systemen unverzichtbar. Sie ermöglichen die Kommunikation zwischen zwei separaten, verteilten Anwendungen oder Services, ohne dass die Interna der jeweils anderen Anwendung bekannt sind. Diese beiden Anwendungen oder Services haben vielleicht nur wenig miteinander zu tun, abgesehen vom Austausch einiger weniger Daten.
APIs sind auch ein gängiger Mechanismus für die Kommunikation zwischen dem Backend eines Programms (der Logikkomponente) und dem Frontend eines Programms (der Anzeigekomponente). Wenn Sie Webseiten und Webanwendungen mit APIs anstelle von eng gekoppelter Integration entwerfen, stellen Sie sicher, dass sie skalierbar sind und mit weniger neu zu schreibendem Code geändert werden können.
Im Folgenden werden weitere Gemeinsamkeiten zwischen RPC- und REST-APIs erörtert.
Abstraktion
Während die Netzkommunikation das Hauptziel von APIs ist, wird die Kommunikation auf unterer Ebene von den API-Entwicklern abstrahiert. Dadurch können sich Entwickler eher auf die Funktion als auf die technische Umsetzung konzentrieren.
Kommunikation
Sowohl REST als auch RPC verwenden HTTP als zugrundeliegendes Protokoll. Die beliebtesten Nachrichtenformate in RPC und REST sind JSON und XML. JSON wird aufgrund seiner Lesbarkeit und Flexibilität bevorzugt.
Sprachübergreifende Kompatibilität
Entwickler können eine RESTful- oder RPC-API in einer beliebigen Sprache ihrer Wahl implementieren. Solange das Netzwerkkommunikationselement der API dem RESTful- oder RPC-Schnittstellenstandard entspricht, können Sie den restlichen Code in einer beliebigen Programmiersprache schreiben.
Architekturgrundsätze: RPC vs. REST
Beim Remote Procedure Call (RPC) ruft der Client eine Remote-Funktion (auch Methode oder Prozedur genannt) auf einem Server auf. In der Regel werden während des Aufrufs ein oder mehrere Datenwerte an den Server übergeben.
Im Gegensatz dazu fordert der REST-Client den Server auf, eine Aktion für eine bestimmte Serverressource durchzuführen. Aktionen sind auf das Erstellen, Lesen, Aktualisieren und Löschen (CRUD) beschränkt und werden als HTTP-Verben oder HTTP-Methoden übermittelt.
RPC konzentriert sich auf Funktionen oder Aktionen, während sich REST auf Ressourcen oder Objekte konzentriert.
RPC-Grundsätze
Als Nächstes werden einige Grundsätze erörtert, die RPC-Systeme in der Regel befolgen. Diese Grundsätze sind jedoch nicht wie REST standardisiert.
Fernaufruf
Ein RPC-Aufruf wird von einem Client an eine Funktion auf dem Remote-Server gesendet, als ob sie lokal auf dem Client aufgerufen würde.
Parameterübergabe
Der Client sendet in der Regel Parameter an eine Serverfunktion, ähnlich wie bei einer lokalen Funktion.
Stubs
Funktions-Stubs gibt es sowohl auf dem Client als auch auf dem Server. Auf der Client-Seite erfolgt der Funktionsaufruf. Auf dem Server ruft er die eigentliche Funktion auf.
REST-Grundsätze
REST-Grundsätze sind standardisiert. Eine REST-API muss diese Grundsätze befolgen, um als RESTful eingestuft zu werden.
Client-Server
Die Client-Server-Architektur von REST entkoppelt Clients und Server. Sie behandelt sie jeweils als unabhängige Systeme.
Zustandslos
Der Server speichert keine Aufzeichnungen über den Zustand des Clients zwischen Client-Anfragen.
Cachefähig
Die Client- oder Zwischensysteme können Serverantworten zwischenspeichern, je nachdem, ob ein Client angibt, dass die Antwort zwischengespeichert werden darf.
Mehrstufiges System
Zwischen dem Client und dem Server können Vermittler stehen. Sowohl der Client als auch der Server haben keine Kenntnis davon und arbeiten so, als wären sie direkt miteinander verbunden.
Einheitliche Schnittstelle
Der Client und der Server kommunizieren über einen standardisierten Satz von Anweisungen und Nachrichtenformaten mit der REST-API. Ressourcen werden durch ihre URL identifiziert. Diese URL wird als REST-API-Endpunkt bezeichnet.
So funktionieren sie: RPC vs. REST
Beim Remote Procedure Call (RPC) verwendet der Client HTTP POST, um eine bestimmte Funktion namentlich aufzurufen. Clientseitige Entwickler müssen den Funktionsnamen und die Parameter im Voraus kennen, damit RPC funktioniert.
In REST verwenden Clients und Server HTTP-Verben wie GET, POST, PATCH, PUT, DELETE und OPTIONS, um Optionen auszuführen. Die Entwickler müssen nur die URLs der Serverressourcen kennen und sich nicht mit den einzelnen Funktionsnamen befassen.
Die folgende Tabelle zeigt die Art des Codes, den der Client verwendet, um ähnliche Aktionen in RPC und REST durchzuführen.
| Aktion |
RPC |
REST |
Kommentar |
| Ein neues Produkt zu einer Produktliste hinzufügen |
POST /addProduct HTTP/1.1 HOST: api.example.com Content-Type: application/json {"name": "T-Shirt", "price": "22.00", "category": "Clothes"} |
POST /products HTTP/1.1 HOST: api.example.com Content-Type: application/json {"name": "T-Shirt", "price": "22.00", "category": "Clothes"} |
RPC verwendet POST für die Funktion, REST verwendet POST für die URL. |
| Details eines Produkts abrufen |
POST /getProduct HTTP/1.1 HOST: api.example.com Content-Type: application/json {"productID": "123”} |
GET /products/123 HTTP/1.1 HOST: api.example.com |
RPC verwendet POST für die Funktion und übergibt den Parameter als JSON-Objekt. REST verwendet GET auf der URL und übergibt den Parameter in der URL. |
| Aktualisierung des Preises eines Produkts |
POST /updateProductPrice HTTP/1.1 HOST: api.example.com Content-Type: application/json {"productId": "123", "newPrice": "20.00"} |
PUT /products/123 HTTP/1.1 HOST: api.example.com Content-Type: application/json {"price": "20.00"} |
RPC verwendet POST für die Funktion und übergibt den Parameter als JSON-Objekt. REST verwendet PUT auf URL und übergibt Parameter in URL und als JSON-Objekt. |
| Ein Produkt löschen |
POST /deleteProduct HTTP/1.1 HOST: api.example.com Content-Type: application/json {"productId": "123""} |
DELETE /products/123 HTTP/1.1 HOST: api.example.com |
RPC verwendet POST für die Funktion und übergibt den Parameter als JSON-Objekt. REST verwendet DELETE für die URL und übergibt den Parameter in der URL. |
Hauptunterschiede: vs. REST
Als nächstes werden weitere Unterschiede angeführt.
Zeit der Entwicklung
RPC wurde in den späten 1970er und frühen 1980er Jahren entwickelt, während der Begriff „REST“ erstmals im Jahr 2000 von dem Informatiker Roy Fielding geprägt wurde.
Operatives Format
Eine REST-API verfügt aufgrund von HTTP-Methoden über einen standardisierten Satz von Serveroperationen, RPC-APIs hingegen nicht. Einige RPC-Implementierungen bieten einen Rahmen für standardisierte Operationen.
Format der Datenübergabe
REST kann Daten in jedem Datenformat und in diversen Formate, wie JSON und XML, innerhalb derselben API weitergeben.
Bei RPC-APIs hingegen wird das Datenformat vom Server ausgewählt und bei der Implementierung festgelegt. Sie können spezifische JSON-RPC- oder XML-RPC-Implementierungen haben, der Client bietet dagegen keine Flexibilität.
Bundesstaat
Im Zusammenhang mit APIs bezieht sich Zustandslos auf ein Designprinzip, bei dem der Server keine Informationen über die vorherigen Interaktionen des Clients speichert. Jede API-Anfrage wird unabhängig behandelt und der Server stützt sich nicht auf einen gespeicherten Client-Status, um die Anfrage zu verarbeiten.
REST-Systeme müssen stets zustandslos sein, während RPC-Systeme je nach Design zustandsabhängig oder zustandslos sein können.
Wann zu verwenden: RPC vs. REST
Remote Procedure Call (RPC) wird normalerweise verwendet, um Remotefunktionen auf einem Server aufzurufen, die ein Aktionsergebnis benötigen. Sie können sie verwenden, wenn Sie komplexe Berechnungen benötigen oder eine Remote-Prozedur auf dem Server auslösen wollen, wobei der Prozess für den Client verborgen bleibt.
Dies sind Aktionen, bei denen RPC eine gute Option ist:
- Aufnahme eines Bildes mit der Kamera eines entfernten Geräts
- Einsatz eines Algorithmus für Machine Learning auf dem Server zur Erkennung von Betrug
- Überweisen von Geld von einem Konto auf ein anderes über ein Fernbanking-System
- Neustart eines Servers aus der Ferne
Eine REST-API wird in der Regel verwendet, um Operationen zum Erstellen, Lesen, Aktualisieren und Löschen (CRUD) eines Datenobjekts auf einem Server durchzuführen. Daher eignen sich REST-APIs gut für Fälle, in denen Serverdaten und Datenstrukturen einheitlich offengelegt werden müssen.
Dies sind Aktionen, für die eine REST-API eine gute Option ist:
- Hinzufügen eines Produkts zu einer Datenbank
- Abrufen des Inhalts einer Musikwiedergabeliste
- Adressaktualisierung einer Person
- Löschen eines Blogeintrags
Warum hat REST RPC ersetzt?
Während REST-Web-APIs heute die Norm sind, ist der Remote Procedure Call (RPC) noch nicht verschwunden. Eine REST-API wird in der Regel in Anwendungen verwendet, weil sie für Entwickler einfacher zu verstehen und zu implementieren ist. RPC gibt es jedoch auch weiterhin und wird eingesetzt, wenn es für den jeweiligen Anwendungsfall besser geeignet ist.
Moderne RPC-Implementierungen, wie gRPC, sind inzwischen weit verbreitet. Für einige Anwendungsfälle ist gRPC besser geeignet als RPC und REST. Es ermöglicht die Streaming-Kommunikation zwischen Client und Server anstelle des Datenaustauschmusters „Anfrage und Antwort“.
Zusammenfassung der Unterschiede: RPC vs. REST
| RPC |
REST |
|
| Wie lautet es? |
Ein System ermöglicht es einem entfernten Client, eine Prozedur auf einem Server so aufzurufen, als ob sie lokal wäre. |
Ein Regelwerk, das den strukturierten Datenaustausch zwischen einem Client und einem Server definiert. |
| Wird verwendet für |
die Ausführung von Aktionen auf einem Remote-Server. |
das Erstellen, Lesen, Aktualisieren und Löschen (CRUD) von entfernten Objekte. |
| Beste Passform |
Wenn komplexe Berechnungen erforderlich sind oder ein Remote-Prozess auf dem Server ausgelöst werden soll. |
Wenn Serverdaten und Datenstrukturen einheitlich verfügbar gemacht werden müssen. |
| Zustandsabhängigkeit |
Zustandslos oder zustandsabhängig. |
Zustandslos. |
| Format der Datenübergabe |
In einer einheitlichen Struktur, die vom Server definiert und auf dem Client durchgesetzt wird. |
In einer vom Server selbständig festgelegten Struktur. Innerhalb derselben API können mehrere unterschiedliche Formate übergeben werden. |
Wie kann AWS Ihre API-Anforderungen unterstützen?
Amazon Web Services (AWS) verfügt über eine Reihe von Services und Tools, die API-Designer bei der Erstellung, Ausführung und Verwaltung API-basierter moderner Anwendungen und Services unterstützen. Weitere Informationen finden Sie unter Erstellen moderner Anwendungen in AWS.
Hier finden Sie Beispiele für AWS-Services, mit denen Sie Ihre API-Anforderungen erfüllen können:
- Amazon API Gateway ermöglicht es Entwicklern, APIs in großem Maßstab zu erstellen, zu veröffentlichen und zu verwalten. Mit API Gateway können Sie REST-APIs erstellen, die für containerisierte Microservice-Architekturen und Webanwendungen optimiert sind.
- Elastic Load Balancing (ELB) verteilt den Netzwerkverkehr, um die Skalierbarkeit von Anwendungen zu verbessern. Die Anwendung kann den gRPC-Datenverkehr zwischen Microservices oder zwischen gRPC-fähigen Clients und Services routen und ausgleichen. Dies ermöglicht ein nahtloses gRPC-Datenverkehrsmanagements in Software-Architekturen, ohne dass die zugrunde liegende Infrastruktur für die Clients oder Services der Kunden geändert werden muss.
- Amazon Virtual Private Cloud (Amazon VPC) Lattice ist ein Anwendungsnetzwerkservice, der die Kommunikation zwischen Ihren Diensten konsistent verbindet, überwacht und sichert. Skalieren Sie Rechen- und Netzwerkressourcen automatisch, um HTTP-, HTTPS- und gRPC-Workloads mit hoher Bandbreite zu unterstützen.
Beginnen Sie mit REST-APIs und RPC-APIs (Remote Procedure Call) in AWS, indem Sie noch heute ein Konto erstellen.
