Protocol Buffers (Protobuf) Formatierer

Proto3 vereinfachte die Protobuf-Sprache, indem es die Feld-Labels 'required' und 'optional' entfernte (alle Felder sind standardmäßig optional), Standardwertdeklarationen wegließ und Erweiterungen zugunsten des Any-Typs fallen ließ. Proto3 fügte auch Unterstützung für JSON-Mapping und Maps als erstklassige Funktion hinzu. Die meisten neuen Projekte sollten Proto3 verwenden, es sei denn, sie benötigen Proto2-spezifische Funktionen wie erforderliche Felder oder benutzerdefinierte Standardwerte.

Feldnummern in Protocol Buffers werden im binären Wire-Format verwendet, um Felder zu identifizieren. Sobald eine .proto-Datei verwendet wird, sollten Feldnummern niemals geändert oder wiederverwendet werden – andernfalls wird die Abwärtskompatibilität mit vorhandenen serialisierten Daten gebrochen. Zahlen 1-15 verwenden ein Byte in der Kodierung, daher sollten häufig verwendete Felder aus Effizienzgründen niedrige Nummern erhalten. Der Bereich 19000-19999 ist von der Protobuf-Implementierung reserviert.

Protocol Buffers erzeugen signifikant kleinere Payloads (3-10x kleiner als JSON) und sind schneller zu serialisieren und deserialisieren, da sie ein Binärformat anstelle von Text verwenden. Sie erzwingen außerdem ein strenges Schema, das Datentypfehler zur Kompilierzeit und nicht zur Laufzeit erfasst. JSON ist jedoch besser für menschenlesbare APIs, browserbasierte Anwendungen und Situationen geeignet, in denen Flexibilität des Schemas wichtiger ist als Leistung.

gRPC verwendet Protocol Buffers sowohl als IDL (Interface Definition Language) als auch als zugrundehendes Nachrichtenformat für die Serialisierung. Sie definieren Ihre Service-Methoden und Nachrichtentypen in .proto-Dateien und verwenden dann den protoc-Compiler, um Client- und Servercode in Ihrer Ziel-Sprache zu generieren. gRPC unterstützt vier Kommunikationsmuster: Unary (einzelne Anfrage-Antwort), Server-Streaming, Client-Streaming und bidirektionales Streaming.

Abwärtskompatibilität bedeutet, dass Code, der eine neuere Version eines .proto-Schemas verwendet, immer noch Daten lesen kann, die mit einer älteren Version serialisiert wurden, und umgekehrt. Um dies aufrechtzuerhalten, sollten Sie niemals vorhandene Feldnummern ändern, niemals gelöschte Feldnummern wiederverwenden (verwenden Sie stattdessen das reservierte Schlüsselwort) und nur neue optionale Felder hinzufügen. Das Entfernen von erforderlichen Feldern in proto2 oder das Ändern von Feldtypen bricht die Kompatibilität und kann zu Datenbeschädigung oder Parsing-Fehlern führen.