Der Spickzettel für das Systemdesign: API-Stile – REST, GraphQL, WebSocket, Webhook, RPC/gRPC, SOAP

Dies ist eine Fortsetzung einer Artikelreihe, in der ich kurz die Hauptpunkte eines bestimmten Themas im Systemarchitekturdesign beschreibe. Den ersten Artikel können Sie lesen hier Unter API-Architektur versteht man die Reihe von Regeln, Protokollen und Tools, die vorgeben, wie Softwarekomponenten interagieren sollen. Bei der Architektur einer API geht es nicht nur darum, die Kommunikation zu erleichtern. Es geht auch darum sicherzustellen, dass diese Kommunikation effizient, sicher und skalierbar ist. Eine gut gestaltete API-Architektur kann die Leistung eines Systems erheblich steigern, während eine schlecht gestaltete API zu Engpässen, Sicherheitslücken und Wartungsalbträumen führen kann. Verschiedene Stile der API-Architektur Die gängigsten API-Designstile: (Representational State Transfer) ist der am häufigsten verwendete Stil, der Standardmethoden und HTTP-Protokolle verwendet. Es basiert auf Prinzipien wie Zustandslosigkeit, Client-Server-Architektur und Cachefähigkeit. Es wird häufig zwischen Front-End-Clients und Back-End-Diensten verwendet. REST ist eine Abfragesprache für APIs. Im Gegensatz zu REST, das einen festen Satz von Endpunkten für jede Ressource bereitstellt, ermöglicht GraphQL den Clients, genau die Daten anzufordern, die sie benötigen, und reduziert so den übermäßigen Abruf. GraphQL ist ein Protokoll, das eine bidirektionale Kommunikation über TCP ermöglicht. Clients nutzen Web-Sockets, um Echtzeit-Updates von Back-End-Systemen zu erhalten. WebSocket ist ein Mechanismus, der es einem System ermöglicht, ein anderes System in Echtzeit über bestimmte Ereignisse zu benachrichtigen. Es handelt sich um einen benutzerdefinierten HTTP-Callback. Webhook ist ein Protokoll, mit dem ein Dienst eine Prozedur/Methode von einem Dienst anfordern kann, der sich auf einem anderen Computer in einem Netzwerk befindet. Normalerweise ist es für die Kommunikation mit geringer Latenz und hoher Geschwindigkeit konzipiert. RPC (gRPC) ist ein Protokoll zum Austausch strukturierter Informationen zur Implementierung von Webdiensten. Es basiert auf XML und ist für seine Robustheit und Sicherheitsfunktionen bekannt und gilt derzeit als Legacy-Protokoll. SOAP Schauen wir uns jedes Protokoll einzeln mit all seinen Vor- und Nachteilen und Anwendungsfällen an. AUSRUHEN ist ein Architekturstil, der Standardkonventionen und -protokolle verwendet und so leicht zu verstehen und zu implementieren ist. Aufgrund seiner zustandslosen Natur und der Verwendung von Standard-HTTP-Methoden ist es eine beliebte Wahl für die Erstellung webbasierter APIs. REST Während REST lange Zeit der De-facto-Standard für die Erstellung von APIs war, sind andere Stile wie GraphQL entstanden, die unterschiedliche Paradigmen für die Abfrage und Bearbeitung von Daten bieten. : XML, JSON, HTML, einfacher Text Format : HTTP/HTTPS Transportprotokoll Schlüsselkonzepte und Merkmale : In REST ist alles eine Ressource. Eine Ressource ist ein Objekt mit einem Typ, zugehörigen Daten, Beziehungen zu anderen Ressourcen und einer Reihe von Methoden, die damit arbeiten. Ressourcen werden durch ihre URIs (normalerweise eine URL) identifiziert. Ressource : REST-Dienste werden häufig direkt CRUD-Operationen (Erstellen, Lesen, Aktualisieren, Löschen) für Ressourcen zugeordnet. CRUD-Operationen : REST-Systeme verwenden Standard-HTTP-Methoden: HTTP-Methoden GET: Eine Ressource abrufen. POST: Erstellen Sie eine neue Ressource. PUT/PATCH: Eine vorhandene Ressource aktualisieren. LÖSCHEN: Eine Ressource entfernen. : REST-APIs verwenden Standard-HTTP-Statuscodes, um den Erfolg oder Misserfolg einer API-Anfrage anzuzeigen: Statuscodes 2xx – Anerkennung und Erfolg 200 - OK 201 – Erstellt 202 – Akzeptiert 3xx – Umleitung 301 – Dauerhaft verschoben 302 – Gefunden 303 – Siehe Andere 4xx – Clientfehler 400 – Ungültige Anfrage 401 nicht Autorisiert 403 Verboten 404 Nicht gefunden 405 – Methode nicht zulässig 5xx – Serverfehler 500 – Interner Serverfehler 501 – Nicht implementiert 502 Bad Gateway 503 Dienst nicht verfügbar 504 – Gateway-Zeitüberschreitung : Jede Anfrage von einem Client an einen Server muss alle Informationen enthalten, die zum Verständnis und zur Verarbeitung der Anfrage erforderlich sind. Der Server sollte nichts über den Status des Clients zwischen Anfragen speichern. Zustandslos : REST basiert auf dem Client-Server-Modell. Der Client ist für die Benutzeroberfläche und das Benutzererlebnis verantwortlich, während der Server für die Verarbeitung von Anfragen, die Handhabung der Geschäftslogik und die Speicherung von Daten verantwortlich ist. Client-Server : Antworten vom Server können vom Client zwischengespeichert werden. Der Server muss angeben, ob eine Antwort zwischenspeicherbar ist oder nicht. Cachebar : Ein Client kann normalerweise nicht erkennen, ob er direkt mit dem Endserver oder einem Vermittler verbunden ist. Zwischenserver können die Skalierbarkeit des Systems verbessern, indem sie einen Lastausgleich ermöglichen und gemeinsam genutzte Caches bereitstellen. Mehrschichtiges System Hypermedia As The Engine Of Application Stat ist ein REST-Webservice-Prinzip, das es Clients ermöglicht, mit einer Webanwendung zu interagieren und durch diese zu navigieren, und zwar vollständig auf der Grundlage der vom Server in seinen Antworten dynamisch bereitgestellten Hypermedia, wodurch eine lose Kopplung und Auffindbarkeit gefördert wird. HATEOAS: Anwendungsfälle : Viele Webdienste stellen ihre Funktionalität über REST-APIs zur Verfügung, sodass Drittentwickler ihre Dienste integrieren und erweitern können. Webdienste : Mobile Apps kommunizieren häufig über REST-APIs mit Backend-Servern, um Daten abzurufen und zu senden. Mobile Anwendungen : SPAs verwenden REST-APIs, um Inhalte dynamisch zu laden, ohne dass eine vollständige Seitenaktualisierung erforderlich ist. Single Page Applications (SPAs) Systeme innerhalb einer Organisation können mithilfe von REST-APIs kommunizieren und Daten austauschen. Integration zwischen Systemen: Beispiel Anfrage GET „/user/42“ Antwort { "id": 42, "name": "Alex", "links": { "role": "/user/42/role" } } GraphQL bietet einen flexibleren, robusteren und effizienteren Ansatz zum Erstellen von APIs, insbesondere in komplexen Systemen oder wenn das Frontend eine hohe Flexibilität erfordert. Dadurch wird ein Teil der Verantwortung vom Server auf den Client verlagert, sodass der Client seine Datenanforderungen festlegen kann. GraphQL Obwohl es nicht in allen Szenarien ein Ersatz für REST ist, bietet es in vielen Situationen eine überzeugende Alternative, insbesondere wenn Anwendungen immer stärker vernetzt und verteilt werden. : JSON Format : HTTP/HTTPS Transportprotokoll Schlüsselkonzepte und Merkmale : Sie ermöglicht es Clients, die benötigten Daten anzufordern, sodass alle erforderlichen Informationen in einer einzigen Anfrage abgerufen werden können. Abfragesprache für APIs : GraphQL-APIs sind nach Typen und Feldern organisiert, nicht nach Endpunkten. Es verwendet ein starkes Typsystem, um die Funktionen einer API zu definieren. Alle in einer API bereitgestellten Typen werden mithilfe der GraphQL Schema Definition Language (SDL) in einem Schema niedergeschrieben. Typsystem : Im Gegensatz zu REST, wo Sie möglicherweise mehrere Endpunkte für verschiedene Ressourcen haben, stellen Sie in GraphQL normalerweise einen einzelnen Endpunkt bereit, der den gesamten Funktionsumfang des Dienstes ausdrückt. Einzelner Endpunkt : Auf der Serverseite sammeln Resolver die in einer Abfrage beschriebenen Daten. Resolver : GraphQL bietet nicht nur die Abfrage von Daten, sondern auch integrierte Unterstützung für Echtzeit-Updates mit Abonnements. Echtzeit-Updates mit Abonnements : Ein GraphQL-Server kann nach den von ihm unterstützten Typen abgefragt werden. Dadurch entsteht ein starker Vertrag zwischen Client und Server, der Tools und eine bessere Validierung ermöglicht. Introspektiv Anwendungsfälle : Für Anwendungen (insbesondere mobile) mit entscheidender Bandbreite möchten Sie die vom Server abgerufenen Daten minimieren. Flexible Frontends : Wenn Sie über mehrere Microservices verfügen, kann eine GraphQL-Ebene eingeführt werden, um die Daten dieser Services in einer einheitlichen API zu aggregieren. Aggregieren von Microservices : Mit seinem Abonnementsystem eignet sich GraphQL hervorragend für Anwendungen, die Echtzeitdaten benötigen, wie Chat-Anwendungen, Live-Sport-Updates usw. Echtzeitanwendungen : Mit REST müssen Sie Ihre APIs oft versionieren, sobald Änderungen eingeführt werden. Mit GraphQL fordern Clients nur die erforderlichen Daten an, sodass das Hinzufügen neuer Felder oder Typen keine bahnbrechenden Änderungen mit sich bringt. Versionsfreie APIs Beispiel Anfrage GET „/graphql?query=user(id:42){ name role { id name } }“ Antwort { "data": { "user": { "id": 42, "name": "Alex", "role": { "id": 1, "name": "admin" } } } } WebSocket bieten einen Vollduplex-Kommunikationskanal über eine einzige, langlebige Verbindung und ermöglichen den Datenaustausch in Echtzeit zwischen einem Client und einem Server. Dadurch ist es ideal für interaktive und leistungsstarke Webanwendungen. WebSockets : Binär Format : TCP Transportprotokoll Schlüsselkonzepte und Merkmale : Im Gegensatz zum herkömmlichen Anfrage-Antwort-Modell bieten WebSockets einen Vollduplex-Kommunikationskanal, der offen bleibt und einen Datenaustausch in Echtzeit ermöglicht. Dauerhafte Verbindung : WebSockets starten als HTTP-Anfrage, die dann auf eine WebSocket-Verbindung aktualisiert wird, wenn der Server dies unterstützt. Dies erfolgt über den Header „Upgrade“. Upgrade-Handshake : Sobald die Verbindung hergestellt ist, werden Daten als Frames übertragen. Über diese Frames können sowohl Text- als auch Binärdaten gesendet werden. Frames : WebSockets ermöglichen eine direkte Kommunikation zwischen Client und Server, ohne dass für jeden Austausch eine neue Verbindung geöffnet werden muss. Dies führt zu einem schnelleren Datenaustausch. Geringe Latenz : Sowohl der Client als auch der Server können unabhängig voneinander Nachrichten aneinander senden. Bidirektional : Nach der ersten Verbindung erfordern Datenrahmen weniger Bytes zum Senden, was zu weniger Overhead und besserer Leistung führt als der wiederholte Aufbau von HTTP-Verbindungen. Weniger Overhead : WebSockets unterstützen Unterprotokolle und Erweiterungen und ermöglichen standardisierte und benutzerdefinierte Protokolle zusätzlich zum Basis-WebSocket-Protokoll. Protokolle und Erweiterungen Anwendungsfälle : Echtzeit-Multiplayer-Spiele, bei denen die Aktionen der Spieler sofort auf andere Spieler übertragen werden müssen. Online-Gaming : Anwendungen wie Google Docs, bei denen mehrere Benutzer gleichzeitig ein Dokument bearbeiten und die Änderungen des anderen in Echtzeit sehen können. Kollaborative Tools : Aktienhandelsplattformen, auf denen Aktienkurse in Echtzeit aktualisiert werden müssen. Finanzanwendungen : Jede Anwendung, bei der Benutzer Echtzeitbenachrichtigungen erhalten müssen, z. B. Social-Media-Plattformen oder Messaging-Apps. Benachrichtigungen : Nachrichten-Websites oder Social-Media-Plattformen, auf denen neue Beiträge oder Updates live an Benutzer gestreamt werden. Live-Feeds Beispiel Anfrage GET „ws://site:8181“ Antwort HTTP/1.1 101 Switching-Protokolle Webhook ist ein benutzerdefinierter HTTP-Rückruf, der durch bestimmte Webanwendungsereignisse ausgelöst wird und Datenaktualisierungen und Integrationen zwischen verschiedenen Systemen in Echtzeit ermöglicht. Webhook : XML, JSON, Klartext Format : HTTP/HTTPS Transportprotokoll Schlüsselkonzepte und Merkmale : Webhooks werden normalerweise verwendet, um anzuzeigen, dass ein Ereignis aufgetreten ist. Anstatt Daten in regelmäßigen Abständen anzufordern, stellen Webhooks Daten bereit, sobald sie auftreten, und stellen so das herkömmliche Anfrage-Antwort-Modell auf den Kopf. Ereignisgesteuert : Webhooks sind im Wesentlichen ein benutzerdefinierter Rückrufmechanismus. Wenn ein bestimmtes Ereignis eintritt, führt die Quellsite einen HTTP-Rückruf an den von der Zielsite bereitgestellten URI durch, der dann eine bestimmte Aktion ausführt. Rückrufmechanismus : Wenn der Webhook ausgelöst wird, sendet die Quellseite Daten (Nutzlast) an die Zielseite. Diese Daten liegen typischerweise in der Form von JSON oder XML vor. Nutzlast : Webhooks ermöglichen es Anwendungen, Echtzeitdaten abzurufen, wodurch sie sehr reaktionsfähig sind. Echtzeit : Benutzer oder Entwickler können normalerweise definieren, über welche spezifischen Ereignisse sie benachrichtigt werden möchten. Anpassbar : Da Webhooks Rückrufe an benutzerdefinierte HTTP-Endpunkte beinhalten, können sie Sicherheitsrisiken mit sich bringen. Es ist von entscheidender Bedeutung, sicherzustellen, dass der Endpunkt sicher ist, die Daten validiert und möglicherweise verschlüsselt sind. Sicherheit Anwendungsfälle : Auslösen von Builds und Bereitstellungen, wenn Code gepusht oder eine Pull-Anfrage zusammengeführt wird. Kontinuierliche Integration und Bereitstellung (CI/CD) : Benachrichtigung nachgelagerter Systeme, wenn Inhalte aktualisiert, veröffentlicht oder gelöscht werden. Content-Management-Systeme (CMS) : Informieren von E-Commerce-Plattformen über Transaktionsergebnisse, wie erfolgreiche Zahlungen, fehlgeschlagene Transaktionen oder Rückerstattungen. Zahlungsgateways : Empfangen von Benachrichtigungen über neue Beiträge, Erwähnungen oder andere relevante Ereignisse auf Social-Media-Plattformen. Social-Media-Integrationen : Geräte oder Sensoren können Webhooks auslösen, um andere Systeme oder Dienste über bestimmte Ereignisse oder Datenablesungen zu benachrichtigen. IoT (Internet der Dinge) Beispiel Anfrage GET „ “ https://external-site/webhooks?url=http://site/service-h/api&name=name Antwort { "webhook_id": 12 } RPC und gRPC (Remote Procedure Call) ist ein Protokoll, das es einem Programm ermöglicht, eine Prozedur oder Unterroutine in einem anderen Adressraum auszuführen und so eine nahtlose Kommunikation und einen nahtlosen Datenaustausch zwischen verteilten Systemen ermöglicht. RPC (Google RPC) ist ein modernes Open-Source-Framework, das auf RPC aufbaut und HTTP/2 für den Transport und Protokollpuffer als Schnittstellenbeschreibungssprache verwendet. Es bietet Funktionen wie Authentifizierung, Lastausgleich und mehr, um eine effiziente und robuste Kommunikation zu ermöglichen zwischen Microservices. gRPC RPC : JSON, XML, Protobuf, Thrift, FlatBuffers Format : Verschiedene Transportprotokoll Schlüsselkonzepte und Merkmale : RPC ermöglicht es einem Programm, die Ausführung einer Prozedur (Unterroutine) in einem anderen Adressraum (üblicherweise auf einem anderen Computer in einem gemeinsam genutzten Netzwerk) zu veranlassen. Es ist, als würde man eine Funktion aufrufen, die auf einem anderen Computer als dem des Aufrufers ausgeführt wird. Definition : Im RPC-Kontext sind Stubs von Tools generierte Codeteile, die es ermöglichen, dass lokale und Remote-Prozeduraufrufe gleich aussehen. Der Client verfügt über einen Stub, der wie die Remote-Prozedur aussieht, und der Server verfügt über einen Stub, der Argumente entpackt, die eigentliche Prozedur aufruft und dann die Ergebnisse zum Zurücksenden packt. Stubs : Herkömmliche RPC-Aufrufe blockieren, was bedeutet, dass der Client eine Anfrage an den Server sendet und blockiert wird, während er auf eine Antwort vom Server wartet. Standardmäßig synchron : Viele RPC-Systeme ermöglichen die Kommunikation verschiedener Client- und Serverimplementierungen, unabhängig von der Sprache, in der sie geschrieben sind. Sprachneutral : RPC erfordert häufig, dass Client und Server die aufgerufene Prozedur, ihre Parameter und ihren Rückgabetyp kennen. Enge Kopplung Anwendungsfälle : RPC wird häufig in verteilten Systemen verwendet, bei denen Teile eines Systems über verschiedene Maschinen oder Netzwerke verteilt sind, aber so kommunizieren müssen, als ob sie lokal wären. Verteilte Systeme : NFS (Network File System) ist ein Beispiel für RPCs, die Dateioperationen remote ausführen. Netzwerkdateisysteme Beispiel Anfrage { "method": "addUser", "params": [ "Alex" ] } Antwort { "id": 42, "name": "Alex", "error": null } gRPC : Protobuf Format : HTTP/2 Transportprotokoll Schlüsselkonzepte und Merkmale : gRPC ist ein von Google entwickeltes Open-Source-RPC-Framework. Es verwendet HTTP/2 für den Transport, Protokollpuffer (Protobuf) als Schnittstellenbeschreibungssprache und bietet Authentifizierung, Lastausgleichsfunktionen und mehr. Definition : Dies ist ein sprachneutraler, plattformneutraler, erweiterbarer Mechanismus zur Serialisierung strukturierter Daten. Mit gRPC definieren Sie Dienstmethoden und Nachrichtentypen mithilfe von Protobuf. Protokollpuffer : gRPC ist für Kommunikation mit geringer Latenz und hohem Durchsatz konzipiert. HTTP/2 ermöglicht das Multiplexen mehrerer Anrufe über eine einzige Verbindung und reduziert den Overhead. Leistung : gRPC unterstützt Streaming-Anfragen und -Antworten und ermöglicht so komplexere Anwendungsfälle wie langlebige Verbindungen, Echtzeit-Updates usw. Streaming : Mit gRPC können Clients angeben, wie lange sie auf den Abschluss eines RPC warten sollen. Der Server kann dies überprüfen und entscheiden, ob der Vorgang abgeschlossen oder abgebrochen werden soll, wenn er wahrscheinlich zu lange dauert. Fristen/Zeitüberschreitungen : gRPC ist so konzipiert, dass es Plug-in-Authentifizierung, Lastausgleich, Wiederholungsversuche usw. unterstützt. Pluggable : Wie RPC ist gRPC sprachunabhängig. Mit Protobuf und den gRPC-Tools ist es jedoch einfach, Client- und Servercode in mehreren Sprachen zu generieren. Sprachneutral Anwendungsfälle : gRPC wird aufgrund seiner Leistungsmerkmale und der Möglichkeit, Serviceverträge einfach zu definieren, häufig in Microservices-Architekturen verwendet. Microservices : Aufgrund seiner Streaming-Unterstützung eignet sich gRPC für Echtzeitanwendungen, bei denen Server Daten in Echtzeit an Clients übertragen. Echtzeitanwendungen : Aufgrund seiner Leistungsvorteile und Streaming-Funktionen eignet sich gRPC gut für mobile Clients, die mit Back-End-Diensten kommunizieren. Mobile Clients Beispiel message User { int id = 1 string name = 2 } service UserService { rpc AddUser(User) returns (User); } SEIFE steht für Simple Object Access Protocol und ist ein Protokoll zum Austausch strukturierter Informationen zur Implementierung von Webdiensten in Computernetzwerken. Dabei handelt es sich um ein XML-basiertes Protokoll, das es Programmen ermöglicht, die auf unterschiedlichen Betriebssystemen laufen, miteinander zu kommunizieren. SOAP : XML Format : HTTP/HTTPS, JMS, SMTP und mehr Transportprotokoll Schlüsselkonzepte und Merkmale : SOAP-Nachrichten sind in XML formatiert und enthalten die folgenden Elemente: XML-basiert : Das Stammelement einer SOAP-Nachricht, das das XML-Dokument als SOAP-Nachricht definiert. Umschlag : Enthält alle optionalen Attribute der Nachricht, die bei der Verarbeitung der Nachricht verwendet werden, entweder an einem Zwischenpunkt oder am endgültigen Endpunkt. Header : Enthält die XML-Daten, aus denen die gesendete Nachricht besteht. Text : Ein optionales Fault-Element, das Informationen über Fehler bei der Verarbeitung der Nachricht bereitstellt. Fault : SOAP kann mit jedem Programmiermodell verwendet werden und ist nicht an ein bestimmtes Modell gebunden. Neutralität : Es kann auf jedem Betriebssystem und in jeder Sprache ausgeführt werden. Unabhängigkeit : Jede Anfrage von einem Client an einen Server muss alle Informationen enthalten, die zum Verständnis und zur Verarbeitung der Anfrage erforderlich sind. Zustandslos : Das Fault-Element in einer SOAP-Nachricht wird für die Fehlerberichterstattung verwendet. Integrierte Fehlerbehandlung : Arbeitet auf der Grundlage klar definierter Standards, einschließlich der SOAP-Spezifikation selbst, sowie verwandter Standards wie WS-ReliableMessaging zur Gewährleistung der Nachrichtenzustellung, WS-Security zur Nachrichtensicherheit und mehr. Standardisiert Anwendungsfälle : SOAP wird aufgrund seiner Robustheit, Erweiterbarkeit und Fähigkeit, Firewalls und Proxys zu überwinden, häufig in Unternehmensumgebungen verwendet. Unternehmensanwendungen : Viele Webdienste, insbesondere ältere, verwenden SOAP. Dazu gehören Dienste, die von großen Unternehmen wie Microsoft und IBM angeboten werden. Webdienste : Die integrierte Sicherheit und Erweiterbarkeit von SOAP machen es zu einer guten Wahl für Finanztransaktionen, bei denen Datenintegrität und -sicherheit von größter Bedeutung sind. Finanztransaktionen : Telekommunikationsunternehmen nutzen SOAP möglicherweise für Prozesse wie die Abrechnung, bei denen verschiedene Systeme zuverlässig kommunizieren müssen. Telekommunikation Beispiel Anfrage Alex Antwort 42 Alex Abschluss Die Landschaft der API-Architekturstile ist vielfältig und bietet verschiedene Ansätze wie REST, SOAP, RPC und mehr, jeder mit einzigartigen Stärken und Anwendungsfällen, sodass Entwickler das am besten geeignete Paradigma für den Aufbau skalierbarer, effizienter und robuster Integrationen zwischen unterschiedlicher Software wählen können Komponenten und Systeme.