gRPC, OpenAPI und REST verstehen und wann sie im API-Design eingesetzt werden sollten (2020)

API-Management

gRPC und REST: Verständnis von gRPC, OpenAPI und REST im API-Design und wann man sie einsetzt

• API-Designmodelle: Für das API-Design werden hauptsächlich zwei Modelle verwendet: RPC und REST. Die meisten modernen APIs werden auf Basis des HTTP-Protokolls implementiert.
• gRPC: Eine Technologie zur Implementierung von RPC-APIs, die HTTP 2.0 als Transportprotokoll verwendet. Google und andere nutzen häufig APIs, die die Ideen von RPC und HTTP kombinieren.
• Drei zentrale Verwendungsweisen von HTTP:
  1. REST: Der Client verwendet die vom Server bereitgestellten URLs direkt und muss das URL-Format nicht verstehen.
  2. gRPC: Nutzt HTTP/2, aber HTTP wird dem API-Designer nicht offengelegt.
  3. OpenAPI: Der Client ruft die API mithilfe von URL-Pfad-Templates auf.

REST

• Merkmale: Der Client muss das URL-Format nicht verstehen, und die URL ist kein Teil der API-Spezifikation.
• Vorteile: Bietet die Vorzüge des Webs wie Stabilität, Konsistenz und Allgemeingültigkeit. Das entitätsorientierte Modell ist einfacher und leichter zu verstehen.

gRPC

• Merkmale: Verwendet HTTP/2, aber die Details von HTTP sind verborgen. Der Client nutzt die API, indem er Prozeduren aufruft und Parameter übergibt.
• Vorteile: Clientseitige Programmbibliotheken lassen sich leicht erzeugen, und die Performance ist gut.

OpenAPI

• Merkmale: Die API wird über URL-Pfad-Templates aufgerufen, daher muss der Client das URL-Format verstehen.
• Vorteile: Zugriff auf die API ist allein mit standardmäßigen HTTP-Technologien möglich. Clientseitige Programmbibliotheken können erzeugt werden.

Vergleich von gRPC und OpenAPI

• Gemeinsamkeiten: Beide können als RPC Interface Definition Language (IDL) verwendet werden.
• Unterschiede: gRPC verbirgt die HTTP-Details, OpenAPI legt die HTTP-Details offen.

Vorteile von REST

• Entitätsorientiertes Modell: Einfacher und leichter zu verstehen und auch über längere Zeit stabil.

Verwendung von OpenAPI

• Pfaddefinition: Die API wird mithilfe von Pfaden und HTTP-Methoden definiert.

Vor- und Nachteile von OpenAPI

• Vorteile: Dem RPC-Modell ähnlich und daher für Programmierer vertraut. Lässt sich auf HTTP-Anfragen abbilden.
• Nachteile: Das Design der HTTP-Details erfordert viel Aufwand.

Vorteile von gRPC

• Einfache Implementierung: Die serverseitige Implementierung ist einfach, und clientseitige Bibliotheken lassen sich leicht erzeugen.
• Performance: Durch die Verwendung binärer Payloads effizient.

Nachteile von gRPC

• Spezielle Software erforderlich: Sowohl Client als auch Server benötigen spezielle Software.
• Eingeschränkte Proxy-Funktionalität: Anders als bei HTTP-APIs ist es schwierig, Funktionen in Proxys zu erweitern oder zu ändern.

Fazit

• Wahl des API-Designs: REST, OpenAPI und gRPC sollten jeweils unter Berücksichtigung ihrer Vor- und Nachteile ausgewählt werden.
• Aspekte beim Einsatz von gRPC: Besonders vorteilhaft bei internen APIs oder wenn Clients keine gRPC-Technologie übernehmen müssen.

[GN⁺]

Hacker-News-Kommentare

• Ich bereue, dass ich gRPC überhaupt gelernt habe. Für Debugging und Feinabstimmung der Konfiguration ging sehr viel Zeit drauf.

  • Es heißt zwar, gRPC verberge die Interna, in der Praxis waren aber viel Debugging und Konfigurationsarbeit nötig.
  • Mit Maven-Plugins, Kompatibilitätsproblemen mit HTTP2 und Firewall-Problemen wurde viel Zeit verschwendet.
  • Die Dokumentation ist schwach, und es war schwierig, Fehlermeldungen gut beobachtbar zu machen.

• Ich baue seit Langem APIs und habe sowohl gRPC als auch HTTP/REST verwendet.

  • Ich finde es seltsam, zwischen OpenAPI und REST einen Gegensatz aufzubauen.
  • OpenAPI ist eine Methode, das Verhalten einer HTTP-API zu dokumentieren, und kann RESTful APIs ausdrücken.
  • gRPC ist ein RPC-Mechanismus zum Austausch von Protocol Buffers.
  • gRPC ist effizient, aber nicht so leistungsfähig wie HTTP-Bibliotheken.

• Ich habe bei FAANG gearbeitet und halte gRPC für nützlich beim Routing interner Services.

  • RPC-Protokolle ermöglichen Arbeit in großem Maßstab und mit hoher Geschwindigkeit.
  • Für Kunden oder das Web würde ich gRPC aber nicht verwenden.

• Solange man kein bidirektionales Streaming macht, halte ich gRPC für Zeitverschwendung.

  • Für RPC-Aufrufe zwischen in verschiedenen Sprachen implementierten Services braucht man viel Middleware.

• In einem Projekt wurde gRPC aus Performancegründen eingeführt, später sind wir aber auf eine JSON-API umgestiegen.

  • Uns fehlte Erfahrung mit gRPC, und das Projekt scheiterte aus mehreren Gründen.

• Mit connectrpc behebe ich derzeit die Probleme von gRPC.

  • Über buf.build lassen sich Proto-Dateien von Drittanbietern einfach importieren.
  • Die automatische SDK-Generierung ist sehr nützlich.

• Ich finde, die Developer Experience mit gRPC ist schlechter als mit REST.

  • Man braucht zusätzliche Tools, und der generierte Client-Code ist komplex.

• Roy Fielding erwähnte, dass man bei einer REST-API nur die initiale URI und standardisierte Medientypen kennen müsse.

• Ich nutze gRPC in Rechenzentren nicht gern.

  • Die Performance ist nicht besonders hoch, und die Qualität der Open-Source-Clients ist niedrig.
  • Bei webbasierten APIs bevorzuge ich wegen der Lesbarkeit JSON, auch wenn es Probleme mit Typabweichungen gibt.

• Ich hatte den Eindruck, dass gRPC außerhalb von Google schwer zugänglich ist.

  • Der gRPC-JS-Client ist schwergewichtig und intransparent.
  • Im Vergleich zur Einfachheit von REST wirkt die Umsetzung verfehlt.