Google-Protokollpuffer vs JSON vs XML [geschlossen]


230

Ich würde gerne die Vor- und Nachteile von kennen

  • Google-Protokollpuffer
  • JSON
  • XML

Ich möchte ein gemeinsames Framework für zwei Anwendungen implementieren, eines in Perl und das zweite in Java. Daher möchten Sie einen gemeinsamen Dienst erstellen, der von beiden Technologien verwendet werden kann, z. B. Perl und Java.

Beide sind Webanwendungen.

Bitte teilen Sie mir Ihre wertvollen Gedanken und Vorschläge dazu mit. Ich habe viele Links auf Google gesehen, aber alle haben gemischte Meinungen.


9
Und Sie denken, dass es hier wahrscheinlich einen Konsens geben wird?
Barmar


1
Vielen Dank. Würde aber gerne mehr Protocol Buffers vs JSON wissen.
Manoj Kathiriya

19
@Barmar Es geht nicht um Konsens, es geht um rationale Entscheidungen, um Vor- und Nachteile, es ist gut, dass die Frage gestellt wurde, bevor die Meta-Polizei begann, die Qualität von SO-Inhalten zu verringern.
Boris Treukhov

Ich habe mich immer stark dagegen ausgesprochen, dass solche Fragen willkürlich geschlossen werden. Tatsache ist jedoch, dass ich, wenn ich mich an ein Projekt berate, das diese Entscheidung treffen muss, viel mehr Informationen möchte, als normalerweise in einem SO-Beitrag angezeigt wird. Jeder Rat, den Sie hier erhalten, ist anekdotisch und basiert auf einer fast vollständigen Unkenntnis der Anforderungen und Einschränkungen Ihres speziellen Projekts.
Michael Kay

Antworten:


279

Json

  • menschlich lesbar / bearbeitbar
  • kann analysiert werden, ohne das Schema im Voraus zu kennen
  • Hervorragende Browserunterstützung
  • weniger ausführlich als XML

XML

  • menschlich lesbar / bearbeitbar
  • kann analysiert werden, ohne das Schema im Voraus zu kennen
  • Standard für SOAP etc.
  • gute Werkzeugunterstützung (xsd, xslt, sax, dom usw.)
  • ziemlich ausführlich

Protobuf

  • sehr dichte Daten (kleine Ausgabe)
  • schwer zu dekodieren, ohne das Schema zu kennen (Datenformat ist intern nicht eindeutig und benötigt Schema zur Klärung)
  • sehr schnelle Verarbeitung
  • nicht für menschliche Augen gedacht (dichte Binärdatei)

Alle haben auf den meisten Plattformen eine gute Unterstützung.

Persönlich verwende ich XML heutzutage selten. Wenn der Verbraucher ein Browser oder eine öffentliche API ist, verwende ich normalerweise json. Für interne APIs verwende ich Protobuf für die Leistung. Das Anbieten beider auf einer öffentlichen API (entweder über Header oder separate Endpunkte) funktioniert ebenfalls gut.


8
XML ist mehr Arbeit zum Dekodieren, aber die Validierung kann gegenüber JSON ein großer Vorteil sein. Wenn Sie Ihr XML mit einem Schema überprüfen, bevor Sie eine darin enthaltene Zahlungstransaktion verarbeiten, erhalten Sie eine zusätzliche Robustheitsebene.
CC.

11
XML ermöglicht auch einen narrativen Stil, bei dem Text mit Tags wie Einschlüssen wie abgewechselt wird <value>This is a <attention>narrative style</attention>. Tags could appear <exclamation /> in the middle of text</value>. Dies ist die einzigartige Funktion von XML im Vergleich zu JSON- und Protokollpuffern.
Paul

3
@Marc Gravell: Wie wäre es mit Vorwärtskompatibilität? Ich habe den Eindruck, dass dies eines der großen Verkaufsargumente von protobuf ist.
Thomas Ahle

1
Igor Ganapolsky Ich verstehe, dass dies konzeptionell so gut wie unmöglich ist, da für Protobuffs nur sehr wenig bis gar kein Parsing erforderlich ist, während die Verarbeitungsphase bei json lang und unvermeidlich ist.
Jules GM

3
Nur um zu erwähnen, dass Sie Schemas auch mit JSON verwenden können.
Jesus Angulo
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.