0Pricing
PHP Academy · Lektion

Servicekommunikation: REST und gRPC

Dienste synchron und effizient verbinden

Servicekommunikation: REST und gRPC ist eine kostenlose PHP Academy-Lektion auf CoddyKit. Dies ist Lektion 2 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des PHP Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der PHP Academy-Kurs umfasst insgesamt 4 Lektionen.

REST und gRPC

Services müssen synchron miteinander kommunizieren: Eine Anfrage wird gesendet, eine Antwort kommt zurück. Die beiden vorherrschenden Optionen sind REST über HTTP/JSON und gRPC über HTTP/2 + Protobuf. Sie sind auf unterschiedliche Ziele optimiert — REST auf Reichweite und Benutzerfreundlichkeit, gRPC auf Geschwindigkeit und strikte Verträge.

Diese Lektion zeigt beide Ansätze aus der PHP-Perspektive und erklärt, wann Sie welchen wählen sollten.

REST: die Lingua franca

REST bildet Ressourcen hinter URLs ab und verwendet HTTP-Methoden und Statuscodes für die Semantik. Zu den Stärken gehören universelle Werkzeuge, Caching-Fähigkeit, gute Debugbarkeit mit curl und dass keine speziellen Client-Anforderungen bestehen. Zu den Schwächen gehören ausführliches JSON, kein erzwungenes Schema und die Beschränkung auf Anfrage und Antwort.

Für öffentliche APIs und browserseitig angesprochene Endpunkte ist REST fast immer die richtige Wahl.

Einen REST-Service aufrufen

Verwenden Sie einen PSR-18-HTTP-Client (hier Guzzle). Setzen Sie immer ein Verbindungs- und Anfrage-Timeout — ein unbegrenzter Aufruf eines langsamen Peers kann Ihre PHP-FPM-Worker erschöpfen und den Ausfall kaskadieren lassen.

<?php
require 'vendor/autoload.php';
use GuzzleHttp\Client;

$http = new Client([
    'base_uri'        => 'http://customers-svc/',
    'connect_timeout' => 1.0,  // never block forever on connect
    'timeout'         => 3.0,  // total request budget
    'http_errors'     => false,
]);

$res = $http->get('customers/42', ['headers' => ['Accept' => 'application/json']]);
if ($res->getStatusCode() === 200) {
    $customer = json_decode((string) $res->getBody(), true);
    echo $customer['email'] . "\n";
}

Statuscodes sind der Vertrag

Bei REST-Kommunikation zwischen Services sind HTTP-Statuscodes Ihr Fehlerprotokoll. Behandeln Sie sie bewusst:

  • 2xx bedeutet Erfolg; 4xx bedeutet einen Fehler des Aufrufers (nicht blind wiederholen); 5xx und Timeouts können wiederholt werden.
  • Verwenden Sie 409 für Konflikte, 422 für Validierungsfehler und 429 für Rate-Limits (beachten Sie Retry-After).

Das Wiederholen eines 400 verschwendet nur Aufrufe; das Wiederholen eines 503 mit Backoff ist korrekt.

<?php
function isRetryable(int $status): bool {
    return $status === 0          // timeout/connection error
        || $status === 429
        || ($status >= 500 && $status !== 501);
}
var_dump(isRetryable(503)); // true
var_dump(isRetryable(400)); // false

gRPC: Vertragsorientiert und schnell

gRPC verwendet Protocol Buffers: Sie definieren Services und Nachrichten in einer .proto-Datei und generieren anschließend typsichere Client- und Server-Stubs. Über HTTP/2 mit binärem Protobuf ist es deutlich kompakter und latenzärmer als JSON und unterstützt Streaming.

syntax = "proto3";
package customers;

service Customers {
  rpc GetCustomer (GetCustomerRequest) returns (Customer);
}

message GetCustomerRequest { string id = 1; }
message Customer {
  string id = 1;
  string email = 2;
  int32  loyalty_points = 3;
}

PHP-Stubs generieren

Installieren Sie die gRPC-PHP-Erweiterung und das protoc-Plugin und generieren Sie anschließend Client-Klassen aus der .proto-Datei. PHP kann über ext-grpc als vollwertiger gRPC-Client fungieren; ein nativer PHP-gRPC-Server benötigt typischerweise Roadrunner oder Swoole.

pecl install grpc
composer require grpc/grpc google/protobuf

protoc --proto_path=. \
  --php_out=./generated \
  --grpc_out=./generated \
  --plugin=protoc-gen-grpc=$(which grpc_php_plugin) \
  customers.proto

Ein gRPC-Clientaufruf

Generierte Stubs stellen typisierte Anfragen und Antworten bereit. Ein gRPC-Aufruf gibt die Nachricht und ein status-Objekt zurück — prüfen Sie immer den Statuscode, bevor Sie der Antwort vertrauen.

<?php
require 'vendor/autoload.php';
use Customers\CustomersClient;
use Customers\GetCustomerRequest;
use Grpc\ChannelCredentials;

$client = new CustomersClient('customers-svc:50051', [
    'credentials' => ChannelCredentials::createInsecure(),
]);

$req = (new GetCustomerRequest())->setId('42');
[$reply, $status] = $client->GetCustomer($req)->wait();

if ($status->code === \Grpc\STATUS_OK) {
    echo $reply->getEmail(), "\n";
} else {
    fwrite(STDERR, "gRPC error: {$status->details}\n");
}

Schemaentwicklung

Protobuf ist für Vorwärts- und Rückwärtskompatibilität ausgelegt — sofern Sie seine Regeln beachten:

  • Verwenden Sie eine Feldnummer niemals erneut und ändern Sie sie nie. Fügen Sie neue Felder mit neuen Nummern hinzu.
  • Markieren Sie entfernte Felder als reserved, damit die Nummer nicht wiederverwendet werden kann.
  • Alte Clients ignorieren unbekannte Felder; fehlende Felder erhalten die Standardwerte ihres Typs.

JSON/REST bietet Ihnen dies nicht automatisch — Sie stellen die Kompatibilität per Konvention sicher (idealerweise mit einem gemeinsamen OpenAPI-Schema und Contract-Tests).

message Customer {
  string id = 1;
  string email = 2;
  reserved 3;            // old 'loyalty_points', never reuse 3
  reserved "loyalty_points";
  string display_name = 4; // new field, safe additive change
}

Streaming

gRPC unterstützt vier Aufruftypen; REST unterstützt nativ nur den ersten:

  • Unär — eine Anfrage, eine Antwort.
  • Server-Streaming — eine Anfrage, ein Strom von Antworten (z. B. Live-Aktualisierungen).
  • Client-Streaming — ein Strom von Anfragen, eine Antwort (z. B. Bulk-Upload).
  • Bidirektional — beide Seiten streamen gleichzeitig.

Wenn Ihr Anwendungsfall Push oder einen langlebigen Datenfluss erfordert, ist gRPC-Streaming besser geeignet, als einen REST-Endpunkt abzufragen.

Kontext und Deadlines weitergeben

Synchrone Aufrufe bilden Ketten. Daher müssen zwei Dinge mit jeder Anfrage weitergegeben werden: eine Korrelations-/Trace-ID für durchgängiges Tracing und eine Deadline, damit ein langsamer Endpunkt nicht die gesamte Kette blockiert. gRPC bietet Deadlines als festen Bestandteil; in REST bilden Sie sie mit einem schrumpfenden Timeout-Budget nach, das an nachgelagerte Services weitergegeben wird.

<?php
// REST: shrink the remaining budget as the call chain deepens
function forwardHeaders(array $incoming, float $remainingMs): array {
    return [
        'X-Correlation-Id' => $incoming['X-Correlation-Id'] ?? bin2hex(random_bytes(8)),
        // downstream must finish within what's left of our budget
        'X-Timeout-Ms'     => (string) max(0, (int) $remainingMs),
    ];
}
print_r(forwardHeaders(['X-Correlation-Id' => 'trace-9'], 1500));

Zwischen den beiden wählen

Eine praktische Entscheidungshilfe:

  • REST für öffentliche APIs und Partner-APIs, Browser-Clients, einfaches CRUD, leichtes Debugging und breite Cache-Unterstützung.
  • gRPC für interne, volumenstarke und latenzarme Aufrufe zwischen Services, strikt typisierte Verträge und Streaming.

Viele Systeme verwenden beides: gRPC hinter dem Gateway zwischen Services und REST an der Außengrenze für die Außenwelt. Zwingen Sie nicht ein Werkzeug dazu, die Aufgabe des anderen zu übernehmen.

Kurztest

Das passende Protokoll für den jeweiligen Anwendungsfall auswählen.

Zusammenfassung

Synchrone Kommunikation zwischen Services:

  • REST/JSON — universell, gut debuggbar und cache-fähig; Statuscodes sind der Vertrag; setzen Sie immer Timeouts.
  • gRPC/Protobuf — vertragsorientiert, kompakt, schnell und streamingfähig; generieren Sie typisierte PHP-Stubs.
  • Entscheiden Sie anhand der Status- bzw. gRPC-Codes, ob ein Fehler wiederholbar ist; wiederholen Sie niemals Clientfehler.
  • Entwickeln Sie Schemata additiv weiter — verwenden Sie Protobuf-Feldnummern niemals erneut.
  • REST an der Außengrenze und gRPC zwischen internen Services ist eine verbreitete und sinnvolle Aufteilung.

Als Nächstes: das Routing und Auffinden all dieser Services mit Gateways und Service Discovery.

Häufig gestellte Fragen

Ist die Lektion „Servicekommunikation: REST und gRPC“ kostenlos?

Ja — der vollständige Text von „Servicekommunikation: REST und gRPC“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des PHP Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der PHP Academy-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Servicekommunikation: REST und gRPC“?

Dienste synchron und effizient verbinden Du übst PHP Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um PHP Academy zu starten?

Keine Vorkenntnisse erforderlich. PHP Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 2 von 4.

Wie lange dauert die Lektion „Servicekommunikation: REST und gRPC“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser PHP Academy-Lektion Code schreiben und ausführen?

Ja. Jede PHP Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

  1. Vom Monolithen zu Microservices
  2. Servicekommunikation: REST und gRPC
  3. API-Gateways und Service Discovery
  4. Resilienz: Circuit Breaker und Retries
← Zurück zu PHP Academy