Rajoute deux trucs tres chiant en json, qui limitent son intérêt à l'utiliser pour des config:
- pas de commentaires possible. Ca c'est un GROS problème pour la lisibilité humaine.
- l'ordre des champs n'est pas spécifié. Si t'as un outil qui modifie l'objet et serialize à nouveau, ca peut te faire un diff monstre pour pas grand chose, et json est un tres mauvais choix pour ca.
Et les schémas, c'est quand même super pratique pour s'assurer qu'on écrit pas de la merde (ou juste pour éviter les typos). Et avec un ide décent, ca facilite vachement l'écriture d'un document.
L'absence d'attribut sur les champs peut vite devenir problématique aussi. L'exemple de base, c'est la serialization d'objet, ou la class est perdue, et ne peut pas être inclue sans faire de trucs bien crades.
Les défauts ne sont pas tous simples à corriger, bon courage pour intégrer les commentaires ou la validation xsd sans tout peter. Pour rappel, le js de json, c'est pour Javascript, la spec est base sur les objects literals de JavaScript, ca va être compliqué de faire évoluer le standard sans faire évoluer Javascript en même temps.
Bref, c'est comme tout, ca dépend.
Le meilleur compromis dépend surtout de ce que tu cherches à faire. Json est léger, tres simple à comprendre, et tres simple à vérifier (spec courte). XML est beaucoup plus complet et offre un grand nombre de garde fous.
Si t'écrit un microservice pour un service grand public ou la philosophie est "c'est pas cassé tant que PagerDuty gueule pas trop", json est probablement un bon choix.
Si t'écrit un service un peu plus critique que ca, ou la validation des données échangées est tres importante, xml est probablement un bon choix.
[^] # Re: XML sapu et autres billevesées
Posté par groumly . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 9.
Rajoute deux trucs tres chiant en json, qui limitent son intérêt à l'utiliser pour des config:
- pas de commentaires possible. Ca c'est un GROS problème pour la lisibilité humaine.
- l'ordre des champs n'est pas spécifié. Si t'as un outil qui modifie l'objet et serialize à nouveau, ca peut te faire un diff monstre pour pas grand chose, et json est un tres mauvais choix pour ca.
Et les schémas, c'est quand même super pratique pour s'assurer qu'on écrit pas de la merde (ou juste pour éviter les typos). Et avec un ide décent, ca facilite vachement l'écriture d'un document.
L'absence d'attribut sur les champs peut vite devenir problématique aussi. L'exemple de base, c'est la serialization d'objet, ou la class est perdue, et ne peut pas être inclue sans faire de trucs bien crades.
Les défauts ne sont pas tous simples à corriger, bon courage pour intégrer les commentaires ou la validation xsd sans tout peter. Pour rappel, le js de json, c'est pour Javascript, la spec est base sur les objects literals de JavaScript, ca va être compliqué de faire évoluer le standard sans faire évoluer Javascript en même temps.
Bref, c'est comme tout, ca dépend.
Le meilleur compromis dépend surtout de ce que tu cherches à faire. Json est léger, tres simple à comprendre, et tres simple à vérifier (spec courte). XML est beaucoup plus complet et offre un grand nombre de garde fous.
Si t'écrit un microservice pour un service grand public ou la philosophie est "c'est pas cassé tant que PagerDuty gueule pas trop", json est probablement un bon choix.
Si t'écrit un service un peu plus critique que ca, ou la validation des données échangées est tres importante, xml est probablement un bon choix.