Comparaison du schéma JSON avec le schéma XML et leur futur
je cherchais les standards JSON schema et leurs implémentations php correspondantes. Attendant quelque open source là-bas et j'ai été surpris, de ne trouver qu'une seule implémentation de php. J'étais sur l'utilisation de cette technologie (JSON) et le schéma lib pour analyser mes requêtes de navigateur entrantes.
cette activité d'analyse / validation naturelle semble naturelle dans XML et me fait me demander pourquoi ce n'est pas le cas dans JSON.
je me retrouve avec un doute situation. Dois-je poursuivre l'échange de données de ma structure JSON ou passer au XML? j'ai d'abord choisi JSON pour sa simplicité et sa syntaxe moins verbeuse par rapport à XML, mais si je dois redévelopper toutes les normes existantes dans le monde ces arguments deviennent plus légers. J'ai également choisi JSON dans l'espoir de limiter la taille des communications entre mon serveur web et mes applications mobiles. Jouer avec les applications comet, XMPP semble être mis en œuvre et utilisé par de grands noms comme Google, Facebook, pour leur chat en temps réel chat texte ou vidéo basé sur des messages.
ainsi les questions actuelles sont:
- est JSON pour le pauvre développeur de serveur web qui veut savoir ce qui se passe sur son trafic, et se concentrer sur la simplicité (ne vous méprenez pas, ici, je m'inclus)?
- est-ce que IETF draft pour JSON schema est un travail sérieux, puisque seulement peu d'implémentation existe du côté du serveur (PHP)?
- est-ce que je manque quelque chose, ou peut-être, le meilleur modèle de communication est d'envoyer des données en xml au serveur et s'attendre à une réponse json (de nombreuses implémentations JSON schema existent en javascript)?
- ou n'ai-je fait face qu'à la preuve réelle, que cette préoccupation n'a pas été bien servie par la communauté des développeurs parce que les développeurs web utilisant JSON ne testent pas en profondeur leurs données de requête entrantes?
s'il vous Plaît m'aider à comprendre, je suis pas certains de l'expérience ici?
4 réponses
cette activité d'analyse / validation naturelle semble naturelle dans XML et me fait me demander pourquoi ce n'est pas le cas dans JSON.
rappelez-vous ce qui a rendu JSON célèbre: applications web avec une interface utilisateur très riche écrit en JavaScript. JSON était parfait pour cela parce que les données du serveur mappé directement sur les objets JavaScript; appuyez sur une URL GET avec Ajax et récupérer un objet, pas besoin de parsing ou autre chose.
Ces riches interfaces ont fait JavaScript un langage très populaire et JSON a évidemment roulé le long et sa popularité en a fait le meilleur candidat pour renverser "l'angle bracket".
mais XML a une longue histoire derrière elle. C'est une technologie mature avec beaucoup de qui accompagne les spécifications . JSON est en train de rattraper ça.
bien que le projet de spécification ait expiré en mai 2011, le JSON Les partisans de Schema pensent qu'ils ont atteint une version assez proche de la version finale de la spécification. Qui sait ce que le futur réserve à JSON Schema.
j'ai été surpris, de ne trouver qu'une seule implémentation php [...] Est-ce que l'ébauche de l'IETF pour JSON schema est un travail sérieux, puisque seulement peu d'implémentation existe du côté du serveur (PHP) ?
est-ce que cette implémentation PHP valide JSON selon la dernière version du brouillon du schéma JSON? Si oui, est-il nécessaire pour les autres implémentations? Avez-vous besoin de beaucoup d'implémentations pour certifier qu'une spécification est sérieuse? C'est tout comme dire que XSLT 2.0 n'est pas grave parce que Microsoft n'a pas pris la peine de l'implémenter .
comme pour votre dernière question, les données entrantes doivent être validées. Vous ne prenez pas une demande d'utilisateur et de le jeter au serveur et"espérons qu'il colle". Vous le validez; et JSON Schema n'est pas le seul façon de valider les données JSON, donc ne supposez pas que les développeurs Web utilisant JSON ne testent pas en profondeur leurs données de requête entrantes.
en conclusion, ce que j'essaie de dire, c'est que JSON ne peut pas remplacer complètement XML, ou l'inverse. utiliser chaque technologie s'il y a lieu .
vous demandez beaucoup de choses différentes dans votre question et je ne suis pas sûr que j'ai correctement capturé ce que vous cherchez vraiment Mais voici quelques pensées:
alors que vous pouvez représenter des données à la fois dans JSON et XML ils sont tout à fait différent. Je ne vais même pas essayer d'être précis ici, mais j'espère vous donner la bonne idée:
-
JSON est un moyen léger (de)sérialiser et passer clé / valeur et listes de valeurs autour. C'est léger, c'est facile, pratique et certains diront plus lisible que XML. La sérialisation / désérialisation se fait facilement dans toutes les langues.
-
XML extensible markup langue qui ne représente pas seulement les données, mais précise également les règles (ou les protocoles si vous le souhaitez) à leur sujet.
il ne s'agit pas seulement de fournir une schéma. Puisque vous mentionnez XMPP qui choisit XML pour représenter ses protocoles, considérez l'exemple suivant:
disons que dans certaines représentations basées sur XML conçues pour échanger des informations musicales, un élément <album> est défini.
<album>The Contino Sessions</album>
développés pour analyser ce XML sauront comment interpréter la balise. Maintenant, Foo Bar pourrait venir plus tard et construire sur le protocole l'étendant comme tel:
<album foobar:genre="Electronica">The Contino Sessions</album>
les anciens clients ne sachant rien de l'espace de noms foobar continueront à travailler comme d'habitude en ignorant le foobar:genre . Ceux améliorés pour comprendre le foobar analyseront l'annotation du genre. Ceci illustre par exemple comment XML n'est pas simplement une représentation de données. Essayez de penser comment vous feriez la même chose avec JSON. Vous verrez que vous ne pouvez pas avec les mêmes costraints. C'est pourquoi il est très peu probable, par exemple, qu'une implémentation de XMPP puisse être faite dans JSON.
cela dit, XML porte ses propres fardeaux. Il est difficile de construire de bons analyseurs XML. Il est même difficile d'utiliser XML pour une sérialisation simple. La lisibilité humaine est un euphémisme pour désigner les maux de tête lorsqu'il s'agit de comprendre de longs documents, etc.
en bref:
-
" quand vous ne faites que passer des données autour de JSON est très bien et facile.
-
lorsque vous développez un protocole qui sera étendu en différentes façons par des tiers XML est la voie.
-
les Conversions d'avant en arrière sont une mauvaise idée. Vous ne pouvez pas simplement convertir XML en JSON.
il existe de nombreuses solutions de rechange à l'échange de données et nous étudions deux technologies populaires ici. XML est généralement plus grand que JSON, mais XML est plus flexible et peut faire plus de choses. Comme du coca et du Coca Light en termes de sucre.
si vous avez des services qui desservent XML, alors pourquoi ne pas créer un adaptateur pour sérialiser le XML à JSON et servir les deux. On veut juste éviter les trucs de réaménagement en ajoutant une autre couche.
à lire. http://www.thomasfrank.se/xml_to_json.html
la Compression HTTP peut aussi aider à garder les fichiers XML petits à travers le fil.
ma parole. pour les données complexes, J'utiliserai XML, pour les simples, J'utiliserai JSON. Je vais utiliser les deux.
et le futur? Je vais dire que je ne sais pas.
santé!
j'ai trouvé ce utile Google groups #JSON-schema et JSON Schema: spécifier et valider les structures de données JSON .