TL;DR
Verwenden Sie REST für öffentliche APIs und einfache CRUD-Operationen. Verwenden Sie GraphQL, wenn Clients flexible Datenabrufe benötigen und Sie Over-Fetching reduzieren möchten. Verwenden Sie gRPC für die Hochleistungs-Kommunikation von Microservices. Die Modern PetstoreAPI implementiert alle drei Protokolle, sodass Sie für jeden Anwendungsfall das richtige Tool wählen können.
Einleitung
Sie bauen eine API. Sollen Sie REST, GraphQL oder gRPC verwenden? Jedes Protokoll hat leidenschaftliche Befürworter, die behaupten, ihres sei das beste. Die Wahrheit: Sie sind alle gut in verschiedenen Dingen.
REST ist universell und einfach. GraphQL gibt Clients die Kontrolle über den Datenabruf. gRPC ist schnell und effizient für interne Dienste. Die beste Wahl hängt von Ihrem Anwendungsfall ab, nicht davon, welches Protokoll "besser" ist.
Die meisten APIs wählen ein Protokoll und bleiben dabei. Modern PetstoreAPI verfolgt einen anderen Ansatz: Es implementiert REST, GraphQL und gRPC und zeigt, wie dieselbe Tierhandlungs-API über alle drei Protokolle hinweg funktioniert.
In diesem Leitfaden lernen Sie die Stärken und Schwächen jedes Protokolls kennen, sehen reale Beispiele aus der Modern PetstoreAPI und erfahren, wie Sie das richtige Protokoll für Ihre Anforderungen auswählen.
REST: Der universelle Standard
REST (Representational State Transfer) ist das gebräuchlichste API-Protokoll.
Wie REST funktioniert
Ressourcen werden über URLs mit HTTP-Methoden aufgerufen:
GET /pets - List pets
POST /pets - Create pet
GET /pets/{id} - Get pet
PUT /pets/{id} - Update pet
DELETE /pets/{id} - Delete pet
Beispielanfrage:
GET https://petstoreapi.com/v1/pets/019b4132-70aa-764f-b315-e2803d882a24
Beispielantwort:
{
"id": "019b4132-70aa-764f-b315-e2803d882a24",
"name": "Fluffy",
"species": "CAT",
"status": "AVAILABLE",
"price": 299.99
}
REST Stärken
1. Universelle Kompatibilität
Jede Programmiersprache verfügt über HTTP-Bibliotheken. Browser, curl, Postman – alles funktioniert mit REST.
2. Einfach zu verstehen
URLs repräsentieren Ressourcen. HTTP-Methoden repräsentieren Aktionen. Das mentale Modell ist unkompliziert.
3. Cachebar
HTTP-Caching funktioniert sofort. GET-Anfragen können von Browsern, CDNs und Proxies zwischengespeichert werden.
4. Statuslos
Jede Anfrage ist unabhängig. Kein Session-State auf dem Server.
5. Großartige Tools
OpenAPI-Spezifikationen, Swagger UI, API-Test-Tools – REST hat das beste Ökosystem.
REST Schwächen
1. Over-Fetching
Sie erhalten alle Felder, selbst wenn Sie nur eines benötigen:
// You only need the name, but you get everything
{
"id": "019b4132-70aa-764f-b315-e2803d882a24",
"name": "Fluffy",
"species": "CAT",
"status": "AVAILABLE",
"price": 299.99,
"description": "...",
"images": [...],
"vaccinations": [...]
}
2. Under-Fetching (N+1-Problem)
Um ein Haustier und seine Bestellungen zu erhalten, benötigen Sie mehrere Anfragen:
GET /pets/123 # Get pet
GET /pets/123/orders # Get orders
GET /orders/456/items # Get order items
3. Komplexität der Versionierung
Breaking Changes erfordern neue API-Versionen (/v1, /v2).
4. Keine Echtzeit-Updates
REST ist Anfrage-Antwort. Für Echtzeitdaten benötigen Sie Polling oder WebSockets.
Wann REST verwendet werden sollte
- Öffentliche APIs (maximale Kompatibilität)
- Einfache CRUD-Operationen
- Wenn Caching wichtig ist
- Wenn Sie breite Tool-Unterstützung benötigen
- Mobile Apps mit vorhersehbarem Datenbedarf
Modern PetstoreAPI REST-Implementierung
GraphQL: Flexibler Datenabruf
GraphQL ermöglicht es Clients, genau anzugeben, welche Daten sie benötigen.
Wie GraphQL funktioniert
Ein einziger Endpunkt mit einer Abfragesprache:
query {
pet(id: "019b4132-70aa-764f-b315-e2803d882a24") {
name
species
orders {
id
total
items {
product
quantity
}
}
}
}
Antwort:
{
"data": {
"pet": {
"name": "Fluffy",
"species": "CAT",
"orders": [
{
"id": "order-123",
"total": 49.99,
"items": [
{"product": "Cat food", "quantity": 2}
]
}
]
}
}
}
GraphQL Stärken
1. Kein Over-Fetching
Clients fordern nur die Felder an, die sie benötigen:
query {
pet(id: "019b4132-70aa-764f-b315-e2803d882a24") {
name # Only get the name
}
}
2. Kein Under-Fetching
Verwandte Daten in einer Anfrage abrufen:
query {
pet(id: "019b4132-70aa-764f-b315-e2803d882a24") {
name
orders {
items {
product
}
}
}
}
Kein N+1-Problem.
3. Starke Typisierung
GraphQL-Schemas sind stark typisiert. Clients wissen genau, was verfügbar ist.
4. Introspektion
Clients können das Schema abfragen, um verfügbare Operationen zu entdecken:
query {
__schema {
types {
name
fields {
name
type
}
}
}
}
5. Einziger Endpunkt
Alle Operationen laufen über eine URL: /graphql
GraphQL Schwächen
1. Komplexität
GraphQL ist schwieriger zu lernen als REST. Abfragen, Mutationen, Subscriptions, Resolver – es gibt mehr zu verstehen.
2. Caching ist schwieriger
HTTP-Caching funktioniert nicht gut. Sie benötigen benutzerdefinierte Caching-Strategien.
3. Risiko von Überabfragen
Clients können aufwendige Abfragen schreiben:
query {
pets {
orders {
items {
product {
reviews {
author {
pets {
# Infinite depth!
}
}
}
}
}
}
}
}
Sie benötigen Abfragetiefenbegrenzungen und Komplexitätsanalysen.
4. Datei-Uploads sind umständlich
GraphQL wurde nicht für Datei-Uploads konzipiert. Sie benötigen Workarounds.
5. Monitoring ist schwieriger
Alle Anfragen gehen an /graphql. Sie können nicht nach URL überwachen.
Wann GraphQL verwendet werden sollte
- Mobile Apps (Bandbreite reduzieren)
- Komplexe Datenanforderungen
- Wenn Clients Flexibilität benötigen
- Interne APIs mit bekannten Clients
- Wenn Sie Versionierung vermeiden möchten
Modern PetstoreAPI GraphQL-Implementierung
gRPC: Hochleistungs-RPC
gRPC verwendet Protokollpuffer für effiziente Binärkommunikation.
Wie gRPC funktioniert
Definieren Sie Dienste in .proto-Dateien:
service PetService {
rpc GetPet(GetPetRequest) returns (Pet);
rpc ListPets(ListPetsRequest) returns (ListPetsResponse);
rpc CreatePet(CreatePetRequest) returns (Pet);
}
message Pet {
string id = 1;
string name = 2;
string species = 3;
PetStatus status = 4;
}
Client-Code (generiert):
client := pb.NewPetServiceClient(conn)
pet, err := client.GetPet(ctx, &pb.GetPetRequest{
Id: "019b4132-70aa-764f-b315-e2803d882a24",
})
gRPC Stärken
1. Leistung
Protokollpuffer sind kleiner und schneller als JSON:
- 3-10x kleinere Nutzdaten
- 20-100x schnellere Serialisierung
2. Streaming
Integrierte Unterstützung für Server-Streaming, Client-Streaming und bidirektionales Streaming:
rpc WatchPets(WatchPetsRequest) returns (stream Pet);
3. Starke Typisierung
Protokollpuffer erzwingen Typen zur Kompilierungszeit.
4. Codegenerierung
Generieren Sie Client- und Servercode in über 10 Sprachen aus .proto-Dateien.
5. HTTP/2
Multiplexing, Header-Komprimierung und Server-Push.
gRPC Schwächen
1. Nicht Browser-freundlich
Browser unterstützen kein bidirektionales HTTP/2-Streaming. Sie benötigen grpc-web (einen Workaround).
2. Nicht menschenlesbar
Protokollpuffer sind binär. Sie können keinen gRPC-Endpunkt mit curl aufrufen und die Antwort lesen.
3. Schwieriger zu debuggen
Binäre Protokolle sind schwieriger zu inspizieren als JSON.
4. Weniger Tools
Weniger Tools im Vergleich zu REST. Kein Äquivalent zu Swagger UI.
5. Steilere Lernkurve
Protokollpuffer, Codegenerierung und gRPC-Konzepte brauchen Zeit zum Erlernen.
Wann gRPC verwendet werden sollte
- Microservices-Kommunikation
- Hohe Leistungsanforderungen
- Echtzeit-Streaming
- Interne APIs (nicht öffentlich)
- Polyglotte Umgebungen (mehrere Sprachen)
Modern PetstoreAPI gRPC-Implementierung
Direkter Vergleich
| Merkmal | REST | GraphQL | gRPC |
|---|---|---|---|
| Protokoll | HTTP/1.1 oder HTTP/2 | HTTP/1.1 oder HTTP/2 | Nur HTTP/2 |
| Datenformat | JSON (meistens) | JSON | Protokollpuffer (binär) |
| Endpunkte | Mehrere (/pets, /orders) |
Einzeln (/graphql) |
Dienstmethoden |
| Over-Fetching | Häufig | Selten | N/A (Sie definieren Nachrichten) |
| Under-Fetching | Häufig (N+1) | Selten | N/A |
| Caching | Exzellent (HTTP) | Schlecht | Schlecht |
| Browser-Unterstützung | Exzellent | Exzellent | Schlecht (benötigt grpc-web) |
| Tools | Exzellent | Gut | Fair |
| Lernkurve | Einfach | Mittel | Schwer |
| Leistung | Gut | Gut | Exzellent |
| Streaming | Nein (benötigt WebSocket) | Ja (Subscriptions) | Ja (nativ) |
| Versionierung | URL oder Header | Schema-Evolution | Proto-Evolution |
| Am besten für | Öffentliche APIs, CRUD | Flexible Clients | Microservices |
Wie Modern PetstoreAPI alle drei implementiert
Modern PetstoreAPI ist einzigartig: Sie implementiert dieselbe Tierhandlungs-API in REST, GraphQL und gRPC.
Dieselbe Daten, drei Protokolle
Ein Haustier nach ID abrufen:
REST:
GET https://petstoreapi.com/v1/pets/019b4132-70aa-764f-b315-e2803d882a24
GraphQL:
query {
pet(id: "019b4132-70aa-764f-b315-e2803d882a24") {
id
name
species
}
}
gRPC:
pet, err := client.GetPet(ctx, &pb.GetPetRequest{
Id: "019b4132-70aa-764f-b315-e2803d882a24",
})
Alle drei geben dieselben Tierdaten zurück.
Warum alle drei implementieren?
1. Lernen durch Vergleich
Sehen Sie, wie dieselben Operationen in verschiedenen Protokollen funktionieren.
2. Das richtige Tool wählen
Verwenden Sie REST für öffentliche Endpunkte, GraphQL für mobile Apps, gRPC für interne Dienste.
3. Migrationspfad
Beginnen Sie mit REST, fügen Sie GraphQL oder gRPC später hinzu, ohne alles neu schreiben zu müssen.
4. Referenzimplementierung
Modern PetstoreAPI zeigt produktionsreife Muster für alle drei Protokolle.
Weitere detaillierte Beispiele finden Sie im Protokollvergleichsleitfaden.
Testen von Multi-Protokoll-APIs mit Apidog
Apidog unterstützt REST, GraphQL und gRPC in einem Tool.
REST testen
OpenAPI-Spezifikation importieren und automatisierte Tests durchführen:
pm.test("Status is 200", () => {
pm.response.to.have.status(200);
});
pm.test("Pet has required fields", () => {
const pet = pm.response.json();
pm.expect(pet).to.have.property('id');
pm.expect(pet).to.have.property('name');
});
GraphQL testen
GraphQL-Abfragen schreiben und Antworten validieren:
query GetPet($id: ID!) {
pet(id: $id) {
id
name
species
}
}
Apidog validiert gegen das GraphQL-Schema.
gRPC testen
.proto-Dateien importieren und gRPC-Dienste testen:
service: PetService
method: GetPet
request: { "id": "019b4132-70aa-764f-b315-e2803d882a24" }
Apidog generiert Anfragen aus Protokollpuffer-Definitionen.
Protokollübergreifendes Testen
Testen Sie, ob alle drei Protokolle konsistente Daten zurückgeben:
- REST-Endpunkt aufrufen
- GraphQL-Abfrage aufrufen
- gRPC-Methode aufrufen
- Antworten vergleichen
Apidog hilft sicherzustellen, dass Ihre Multi-Protokoll-API konsistent bleibt.
Das richtige Protokoll wählen
Verwenden Sie diesen Entscheidungsbaum:
Ist dies eine öffentliche API?→ Ja: Verwenden Sie REST (maximale Kompatibilität) → Nein: Weiter
Benötigen Sie Echtzeit-Streaming?→ Ja: Verwenden Sie gRPC oder WebSocket → Nein: Weiter
Benötigen Clients flexible Datenabrufe?→ Ja: Verwenden Sie GraphQL → Nein: Weiter
Ist die Leistung kritisch (Microservices)?→ Ja: Verwenden Sie gRPC → Nein: Verwenden Sie REST (einfachste Option)
Beispiele aus der Praxis
- Stripe: REST (öffentliche API, einfach, cachebar)
- GitHub: REST + GraphQL (REST für öffentlich, GraphQL für komplexe Abfragen)
- Google Cloud: gRPC + REST (gRPC für Leistung, REST für Kompatibilität)
- Netflix: GraphQL (mobile Apps benötigen flexible Daten)
- Uber: gRPC (Microservices-Kommunikation)
Können Sie mehrere Protokolle verwenden?
Ja! Modern PetstoreAPI zeigt, wie. Gängige Muster:
- REST für öffentliche API
- GraphQL für mobile Apps
- gRPC für interne Microservices
Jedes Protokoll bedient verschiedene Clients mit unterschiedlichen Anforderungen.
Fazit
REST, GraphQL und gRPC sind keine Konkurrenten – sie sind Werkzeuge für verschiedene Aufgaben. REST ist universell und einfach. GraphQL gibt Clients die Kontrolle. gRPC ist schnell und effizient.
Modern PetstoreAPI implementiert alle drei und zeigt, wie dieselbe API über verschiedene Protokolle hinweg funktioniert. Sie können die REST-Dokumentation, das GraphQL-Schema und die gRPC-Proto-Dateien einsehen, um produktionsreife Beispiele zu sehen.
Verwenden Sie Apidog, um alle drei Protokolle zu testen, Implementierungen zu vergleichen und die Konsistenz Ihrer Multi-Protokoll-API sicherzustellen.
Das beste Protokoll ist das, das Ihr spezifisches Problem löst. Modern PetstoreAPI gibt Ihnen das Wissen, um klug zu wählen.
FAQ
Kann ich REST und GraphQL zusammen verwenden?
Ja. Viele APIs bieten beides an. Verwenden Sie REST für einfache Operationen und GraphQL für komplexe Abfragen. GitHub macht das so.
Ersetzt gRPC REST?
Nein. gRPC ist für interne Microservices gedacht. REST bleibt der Standard für öffentliche APIs aufgrund besserer Kompatibilität und Tools.
Welches Protokoll ist am schnellsten?
gRPC ist am schnellsten aufgrund von Protokollpuffern und HTTP/2. Aber für die meisten APIs ist der Unterschied nicht entscheidend – die Netzwerklatenz dominiert.
Sollte ich von REST zu GraphQL migrieren?
Nur, wenn Sie das Over-Fetching/Under-Fetching-Problem haben. Migrieren Sie nicht nur, weil GraphQL im Trend liegt.
Können Browser gRPC verwenden?
Nicht direkt. Sie benötigen grpc-web, was die Komplexität erhöht. Für Browser-Clients verwenden Sie REST oder GraphQL.
Wie hält Modern PetstoreAPI alle drei Protokolle synchron?
Durch eine gemeinsame Geschäftslogik-Schicht. REST, GraphQL und gRPC sind dünne Protokolladapter über derselben Kern-API.
Welches Protokoll sollten Startups verwenden?
Beginnen Sie mit REST. Es ist einfach, gut verstanden und verfügt über großartige Tools. Fügen Sie GraphQL oder gRPC später hinzu, wenn Sie sie benötigen.
Unterstützt Apidog alle drei Protokolle?
Ja. Apidog unterstützt REST (OpenAPI), GraphQL und gRPC in einem Tool, was das Testen von Multi-Protokoll-APIs wie Modern PetstoreAPI erleichtert.
