VenedyJSON (JavaScript Object Notation) ist ein textbasiertes, leichtgewichtiges Format, das auf der Objektsyntax von JavaScript beruht. Es ist für Menschen leicht zu lesen und zu schreiben und für Maschinen leicht zu parsen und zu erzeugen. Laut json.org ruht JSON auf zwei universellen Strukturen:
- einer Sammlung von Name-Wert-Paaren (Objekt, beginnt mit
{, endet mit}) - einer geordneten Liste von Werten (Array, beginnt mit
[, endet mit])
Ein Wert ist ein String in doppelten Anführungszeichen, eine Zahl, true, false, null, ein Objekt oder ein Array; diese Strukturen lassen sich beliebig verschachteln. JSON ist sprachunabhängig, nutzt aber Konventionen der C-Familie und ist in ECMA-404 als Datenaustausch-Standard festgehalten. In Webanwendungen wird JSON typischerweise zwischen Server und Client übertragen und per JSON.parse() bzw. JSON.stringify() zwischen Text und Objekt umgewandelt.
XML ist das ältere, deutlich verbosere Markup-Format. Es wird unter anderem von SOAP genutzt und beschreibt seine Struktur über Schemata wie XSD. Durch die Tag-basierte Notation entsteht mehr Overhead als bei JSON, dafür bietet XML mächtige Werkzeuge für Validierung, Namensräume und Dokumentstrukturen, was es in Enterprise- und Behördenkontexten weiterhin relevant hält.
Protocol Buffers sind laut protobuf.dev ein sprach- und plattformneutraler, erweiterbarer Mechanismus zur Serialisierung strukturierter Daten, ähnlich wie JSON, aber kleiner und schneller, mit generierten nativen Sprachbindungen. Man definiert die Datenstruktur einmal in einer .proto-Datei; der Proto-Compiler erzeugt daraus Code zum Lesen und Schreiben. Wesentliche Eigenschaften:
- binär und kompakt, geeignet für Pakete typisierter Daten bis zu wenigen Megabyte
- schemagetrieben mit getypten Feldern statt freier Textstruktur
- erweiterbar, ohne bestehende Daten zu invalidieren oder Code zwingend anzupassen
- geeignet sowohl für flüchtigen Netzwerkverkehr als auch für Langzeitspeicherung
Protocol Buffers sind das bei Google am häufigsten genutzte Datenformat und bilden die Basis für gRPC. Nachteil: Die binäre Form ist nicht direkt menschenlesbar und erfordert das Schema zum Interpretieren.
Daneben spielt YAML eine Rolle, vor allem für Konfiguration und Spezifikationen (etwa OpenAPI), weniger für den Laufzeit-Datenaustausch.
Content-Type und Content Negotiation: Laut MDN ist Content Negotiation der HTTP-Mechanismus, um unter derselben URI unterschiedliche Repräsentationen einer Ressource auszuliefern. Bei der server-driven (proaktiven) Aushandlung sendet der Client Header wie Accept, und der Server wählt die passende Variante. Passt keine, antwortet er mit Statuscodes wie 406 Not Acceptable oder 415 Unsupported Media Type. So signalisiert eine API über den Medientyp (etwa application/json oder application/xml), in welchem Format Anfrage und Antwort kodiert sind.
Wann was: JSON ist der pragmatische Standard für Web- und REST-APIs (lesbar, breit unterstützt). XML lohnt sich bei SOAP, strenger Schemavalidierung oder bestehenden Enterprise-Standards. Protocol Buffers passen bei hohem Durchsatz, niedriger Latenz und Service-zu-Service-Kommunikation über gRPC, wo Kompaktheit und Typsicherheit wichtiger sind als direkte Lesbarkeit.
// .proto-Schema (Protocol Buffers)
syntax = "proto3";
message User {
int32 id = 1;
string name = 2;
bool active = 3;
}
// dieselben Daten als JSON
{
"id": 1,
"name": "Anna",
"active": true
}
// HTTP-Aushandlung des Formats
GET /api/user/1
Accept: application/json
-> 200 OK
Content-Type: application/jsonDasselbe Datenobjekt als getyptes Protobuf-Schema und als JSON; der Accept- bzw. Content-Type-Header steuert, welche Repräsentation HTTP ausliefert.
Quellen
- Working with JSON - Learn web development MDN Web Docs
- Introducing JSON (ECMA-404 Data Interchange Standard) json.org
- Overview | Protocol Buffers Documentation protobuf.dev (Google)
- Content negotiation - HTTP MDN Web Docs