google protocol buffers vs json vs XML

Question

J'aimerais connaître les avantages et inconvénients de

1) Google Protocol Buffers
2) JSON
3) XML

Je veux mettre en œuvre un cadre commun pour les deux applications, l'une en Perl et la deuxième en Java. Donc, voudrais créer des services communs qui peuvent être utilisées à la fois par la technologie c'est à dire Perl Et Java.

Les deux sont des web-applications.

S'il vous plaît partagez moi vos précieuses idées et des suggestions sur le. J'ai vu beaucoup de liens sur google, mais tous ont des avis partagés.

Merci !!

Answer 1

Json

• l'homme lisible et modifiable
• peut être analysé sans savoir de schéma à l'avance
• excellente prise en charge du navigateur
• moins verbeux que XML

XML

• l'homme lisible et modifiable
• peut être analysé sans savoir de schéma à l'avance
• standard pour le SAVON, etc
• bonne prise en charge des outils (xsd, xslt, sax, dom, etc)
• assez bavard

Protobuf

• très dense de données (faible puissance)
• dur robuste décoder sans connaître le schéma (format de données est à l'intérieur ambiguë, et les besoins de schéma à préciser)
• traitement très rapide
• pas prévu pour les yeux humains (dense binaire)

Tous ont un bon soutien sur la plupart des plateformes.

Personnellement, j'utilise rarement XML ces jours-ci. Si le consommateur est un navigateur ou d'une API publique, j'ai tendance à utiliser json. Interne de l'Api, j'ai tendance à utiliser protobuf pour la performance. Offrant à la fois sur l'API publique (que ce soit via les en-têtes, ou de séparer les points de terminaison) fonctionne bien aussi.

Answer 2

Protocol buffers

Protocol buffers sont binaires et assez compact. Vous pouvez immédiatement utiliser les données que vous avez reçu en pointant simplement sur la partie droite de la mémoire tampon ("zéro-copie"), après un très léger de l'analyse. Si vous passez beaucoup de chiffres, il peut être tout à fait perceptible. Zéro-copie a plus de sens pour le code C ou C++; Java, Python, etc nombres et les chaînes seront probablement changer la représentation pour s'adapter à la langue.

JSON

JSON est un format textuel. Il est facile à analyser efficacement, et vous pouvez même avoir zéro-copie des chaînes, mais tout le reste doit être analysée. JSON peut devenir un gaspillage si vous passez beaucoup de correspondances avec les mêmes touches ([{"foo":1, "bar":2}, {"foo":3, "bar":4}]), mais la compression avant la transmission (mod_gzip, etc) peut éliminer ce problème.

XML

XML a une très mauvaise représentation, mais il a bien établis de vérification et outils de transformation. E. g. à l'aide de XML Schéma, on peut s'exprimer et de vérifier des contraintes complexes. Il a également une norme de langage de transformation XSLT, joliment homoiconic, mais sa syntaxe est totalement non destinés à l'homme.

De mon point de vue

Si je devais mettre en place deux services de communication, je voudrais prendre JSON.

JSON est le plus simple des trois. JSON est facile à vérifier à l'œil et à écrire à la main. Ceci est très important lors du débogage (et des systèmes distribués rarement le travail correctement la première fois).

Je pourrais envisager de tampons de protocole, si au moins l'une des extrémités de la communication a été la performance est critique (probablement écrit en Java, ou Aller, ou d'une autre haute performance de la langue) et j'ai vu un clair problème de performances en JSON code. Sauf si vous avez un Java backend de communiquer avec des centaines de Perl interfaces, et de quelques microsecondes de latence est important pour vous, je ne pense pas que vous allez voir la différence de performances significative entre JSON et le protocole sur les zones tampons.

Sauf s'il y a une sacrément bonne raison, je n'envisage pas de XML à tous.