Formateur de Protocol Buffers (Protobuf)

Proto3 a simplifié le langage protobuf en supprimant les étiquettes de champ obligatoires et facultatives (tous les champs sont facultatifs par défaut), en abandonnant les déclarations de valeurs par défaut et en supprimant les extensions au profit du type Any. Proto3 a également ajouté la prise en charge de la cartographie JSON et des cartes en tant que fonctionnalité de première classe. La plupart des nouveaux projets devraient utiliser proto3, sauf s'ils ont besoin de fonctionnalités spécifiques à proto2 telles que les champs obligatoires ou les valeurs par défaut personnalisées.

Les numéros de champ dans Protocol Buffers sont utilisés dans le format binaire pour identifier les champs. Une fois qu'un fichier .proto est utilisé, les numéros de champ ne doivent jamais être modifiés ou réutilisés — le faire brise la compatibilité descendante avec les données sérialisées existantes. Les numéros 1-15 utilisent un octet dans l'encodage, donc les champs fréquemment utilisés devraient avoir des numéros bas pour l'efficacité. La plage 19000-19999 est réservée par l'implémentation protobuf.

Protocol Buffers produit des charges utiles nettement plus petites (3 à 10 fois plus petites que JSON) et est plus rapide à sérialiser et désérialiser car il utilise un format binaire plutôt que du texte. Ils imposent également un schéma strict, qui détecte les erreurs de type de données au moment de la compilation plutôt qu'à l'exécution. Cependant, JSON reste meilleur pour les API lisibles par l'homme, les applications basées sur navigateur et les situations où la flexibilité du schéma est plus importante que les performances.

gRPC utilise Protocol Buffers à la fois comme langage de définition d'interface (IDL) et comme format de sérialisation de messages sous-jacent. Vous définissez vos méthodes de service et vos types de messages dans des fichiers .proto, puis utilisez le compilateur protoc pour générer le code client et serveur dans votre langage cible. gRPC prend en charge quatre modèles de communication : unaire (requête-réponse unique), streaming serveur, streaming client et streaming bidirectionnel.

La compatibilité descendante signifie que le code utilisant une version plus récente d'un schéma .proto peut toujours lire les données sérialisées avec une version plus ancienne, et vice versa. Pour maintenir cela, vous ne devez jamais modifier les numéros de champ existants, jamais réutiliser les numéros de champ supprimés (utilisez le mot-clé reserved à la place), et seulement ajouter de nouveaux champs facultatifs. La suppression de champs obligatoires en proto2 ou la modification des types de champ brise la compatibilité et peut entraîner une corruption de données ou des échecs d'analyse.