Un examen approfondi de JSON par rapport à XML, partie 3 : XML et l'avenir de JSON

Dans la partie 2 de cet article, nous avons examiné de plus près JSON en tant qu'échange de données et évalué ses forces et ses faiblesses pour les applications simples par rapport au complexe. JSON se distingue comme le format lisible par l'homme le plus concis et le plus compact, mais sa simplicité de base peut entraîner des implications involontaires lorsqu'il est utilisé pour des cas d'utilisation complexes. Avec JSON comme échange de données, les développeurs sont laissés à eux-mêmes pour implémenter les fonctionnalités qui manquent à JSON lui-même, ce qui se traduit par des solutions couplées et non standard qui tentent de combler l'écart. Pour les solutions d'entreprise soucieuses de garantir un fonctionnement sans erreur, l'utilisation de JSON peut entraîner des modèles indésirables susceptibles d'entraver la qualité, la stabilité et la résilience du code du système face aux futures inconnues. XML offre-t-il des fonctionnalités pour aider les applications à atténuer ce risque ? Les mêmes fonctionnalités peuvent-elles être obtenues avec JSON ? Un examen plus approfondi de XML en tant qu'échange de données révélera ses atouts pour réduire les risques logiciels et fournira aux développeurs une meilleure compréhension des modèles qui pourraient aider à améliorer la qualité de leurs applications.

Dans la partie 3 de cet article, nous allons :

1. Explorez XML en tant qu'échange de données et évaluez ses atouts pour prendre en charge des exigences complexes.
2. Discutez de l'avenir de JSON et explorez des solutions qui apportent les atouts de XML à JSON pour permettre aux développeurs de créer des logiciels plus stables et plus résistants aux bogues et aux futures inconnues.

XML est facilement étiqueté comme l'alternative complexe et verbeuse à JSON. Le site Web w3schools.com, une référence populaire pour les standards du Web, propose à peine 58 mots sur le thème « Pourquoi JSON est meilleur que XML » ¹ . Une évaluation aussi simpliste de JSON par rapport à XML est trompeuse, car XML fournit bien plus qu'un simple échange de données. En fait, XML n'a pas été conçu uniquement pour l'échange de données, mais plutôt comme langage pour spécifier des langages de balisage personnalisés pour n'importe quelle application. Avec sa sémantique stricte, XML a défini une norme pour affirmer l'intégrité des données des documents XML, de n'importe quel sous-langage XML. De nombreux développeurs pensent que "XML a échoué et a été remplacé par JSON", mais cela ne pourrait pas être plus éloigné de la vérité. À l'origine, XML était conçu pour être utilisé pour tous les problèmes d'interopérabilité des données, et à ce jour reste « le format le plus largement utilisé au monde pour représenter et échanger des informations ». ²

JSON est simple et XML est puissant

Dans la partie 2 de cet article, nous avons exploré l'échange de données impliquant des contrats axés sur le consommateur (CDC), l'évolution du protocole et la validation des messages. Avec JSON comme échange de données, notre exemple, la Banque européenne, a été mis au défi de fournir une solution à risque réduit pour l'échange de données avec les détaillants. La banque souhaitait des modèles logiciels qui entraînaient un faible couplage, une encapsulation élevée et une grande résilience face aux futures inconnues. Avec JSON comme échange de données, cependant, la banque a été présentée avec des modèles entraînant le contraire : une faible encapsulation, un couplage élevé et une plus faible résilience face aux futures inconnues.

Reprenons l'exemple de la Banque européenne et remplaçons JSON comme format d'échange de données par XML. Les messages XML suivants sont équivalents au message JSON pour chaque type d'identifiant de compte : SWIFT, IBAN et ACH.

 <message xsi:type="swift" xmlns="urn:bank:message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <code>CTBAAU2S</code> </message> <message xsi:type="iban" xmlns="urn:bank:message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <code>DE91 1000 0000 0123 4567 89</code> </message> <message xsi:type="ach" xmlns="urn:bank:message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <code>379272957729384</code> <routing>021000021</routing> </message>

Malgré la perte immédiate d'efficacité du nombre d'octets bruts, XML justifie sa verbosité en prenant en charge une portée plus large autour de l'échange de données. En encodant les données avec JSON, nous avons pu résoudre les besoins immédiats d'échange de données, mais rien pour prendre en charge plusieurs variantes de message ou leur validation. Pour aborder la portée entourant les contrats axés sur le consommateur, les développeurs devraient implémenter un code personnalisé qui entraînerait un couplage logique entre le format du message, son contenu et l'implémentation fonctionnelle pour son traitement. Alternativement, le développeur peut choisir de reconstituer un puzzle d'une collection de bibliothèques et de frameworks pour répondre aux exigences les plus élevées. Les deux approches se traduisent par un oignon de couches au-dessus de l'échange de données qui sont couplées directement à l'application. En encodant les données avec XML, cependant, nous sommes en mesure de résoudre un grand nombre de besoins sans le couplage.

Les équivalents de message XML utilisent deux caractéristiques particulières du standard XML : les espaces de noms et les types d'instance. L'attribut xmlns="urn:bank:message" spécifie l'espace de noms du message, et l'attribut "xsi:type" spécifie son type d'instance, comme "swift" , "iban" ou "ach" . Ces deux attributs sont des standards XML qui permettent à un processeur de message d'identifier le type du message ainsi que de déréférencer le schéma définissant les règles de validation.

Le schéma XML représente le différenciateur clé entre JSON et XML. Avec un schéma, un développeur peut encapsuler la définition normative du format de message dans un support séparé de l'application et définir des contraintes de valeur fournissant des règles de validation appliquées par les processeurs XML. Un exemple de schéma pour la Banque européenne (avec l'espace de namespace: xmlns="urn:bank:message" ), complet avec les descripteurs de type et les contraintes de valeur, est le document de schéma XML (XSD) suivant :

 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" xmlns="urn:bank:message" targetNamespace="urn:bank:message"> <xs:complexType name="format" abstract="true"/> <xs:complexType name="swift"> <xs:complexContent> <xs:extension base="format"> <xs:sequence> <xs:element name="code"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="[AZ]{6}[A-Z0-9]{2}([A-Z0-9]{3})?"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="iban"> <xs:complexContent> <xs:extension base="format"> <xs:sequence> <xs:element name="code"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="[AZ]{2}\d{2} ?\d{4} ?\d{4} ?\d{4} ?\d{4} ?\d{0,2}"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="ach"> <xs:complexContent> <xs:extension base="format"> <xs:sequence> <xs:element name="code"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="\w{1,17}"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="routing"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="\d{9}"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="message" type="format"/> </xs:schema>

Ce schéma XML est logiquement équivalent à la fonction isValid(message) de la partie 2. À première vue, ce schéma XML est considérablement plus verbeux que isValid(message) . La différence fondamentale entre les deux, cependant, est que isValid(message) est couplé à l'application et que le schéma XML ne l'est pas. Le schéma XML est un langage permettant d'exprimer des contraintes sur les documents XML et il existe plusieurs langages de schéma différents largement utilisés, dont les principaux sont : les définitions de type de document (DTD), Relax-NG, Schematron et les définitions de schéma XML du W3C (XSD ). ³ Pour la Banque européenne, le schéma XML fournit une solution à risque réduit aux exigences de niveau supérieur sans le couplage.

Un schéma XML réduit le risque logiciel. Avec XML, les règles de validation des messages sont exprimées dans un langage de schéma disjoint et donc non couplé à l'application. Le schéma XML étant totalement détaché du système, la signification logique du format du message et l'implémentation fonctionnelle de son traitement sont découplées. Le schéma XML donne à la Banque européenne une couche encapsulée qui est seule responsable du contexte de validation des messages, de la variabilité, de la gestion des versions, etc.

Le schéma XML représente la définition normative du contrat axé sur le consommateur. Pour la Banque européenne, cela fournit une approche atténuée des risques pour réduire $\xi_0$ plus près de 0. Étant donné que le schéma est découplé de la banque et du détaillant, les deux parties peuvent l'utiliser pour valider et faire respecter le contrat.

Pourquoi le schéma XML est-il si verbeux ?

La spécification de schéma XML fournit un langage permettant aux développeurs d'implémenter des modèles structurels et logiques utilisés pour définir et contraindre toutes les parties constitutives de tout document XML. Avec un schéma XML, les développeurs peuvent intégrer une signification plus profonde dans chaque partie structurelle et logique d'un document XML. Par exemple, le schéma XML permet :

1. Définition des contraintes d'expressions régulières pour les chaînes constitutives,
2. Définition des plages et des formats des numéros de constituants,
3. Définition des éléments constitutifs et attributs obligatoires et facultatifs,
4. Définition des exigences clés et de référence dans un document, et bien plus encore.

Avec un schéma XML, un système peut s'appuyer sur des validateurs XML génériques pour affirmer la validité de chaque message d'entrée, réduisant intrinsèquement « l'espace d'erreur » $\xi_0$ plus près de 0 et isolant automatiquement la logique métier des entrées erronées.

Le risque du développement futur

Les systèmes peuvent utiliser les fonctionnalités inhérentes à la spécification XML pour réduire le risque logiciel du développement futur. En s'accordant sur un contrat normatif sous la forme d'un schéma XML, les systèmes définissent les règles et les contraintes pour tous les objets et propriétés (éléments et attributs, pour XML) à échanger. Les systèmes sont ensuite en mesure de tirer parti de la portée plus large de la spécification XML pour gérer la variabilité des messages, la gestion des versions de protocole et la validation du contenu. Par exemple, les espaces de noms XML fournissent aux messages XML les informations nécessaires pour :

1. Identifiez la version du message.
2. Déréférencer le schéma contractuel normatif.
3. Valider l'exactitude d'un document.

Avec le large éventail de fonctionnalités et de capacités offertes par le schéma XML, la plupart des exigences complexes entourant l'échange de données peuvent être résolues avec XML lui-même. C'est ce à quoi faisait référence le Dr Charles Goldfarb lorsqu'il a dit « [XML est] le Saint Graal de l'informatique ». ⁴

Le schéma XML aide les applications à être résilientes aux erreurs et malléables aux changements futurs.

XML est une spécification largement acceptée et soigneusement vérifiée avec d'innombrables bibliothèques disponibles pour toutes les plates-formes pour faciliter le traitement et la validation des documents XML. Avec XML comme format d'échange de données, un développeur est en mesure de résoudre les exigences immédiates ainsi que celles concernant les contrats axés sur les consommateurs, la variabilité des messages, la gestion des versions de protocole et la validation du contenu. XML permet à un développeur de se prémunir contre le risque d'exigences complexes et, plus important encore, d'inconnues futures.

XML est bien plus qu'un échange de données et peut être utilisé pour résoudre des problèmes beaucoup plus importants qu'avec JSON. Vue sous cet angle, la portée de XML couvre une plus grande partie de l'oignon, plusieurs des couches de l'oignon étant contenues dans la portée de XML lui-même.

Lors du choix du meilleur format d'échange de données pour une application, est-ce seulement le centre de l'oignon qui nous intéresse, ou est-ce l'oignon en entier ?

Les différences fondamentales entre JSON et XML

XML offre bien plus que l'échange de données et peut être utilisé pour résoudre des problèmes beaucoup plus importants qu'avec JSON. L'étendue des exigences complexes entourant l'échange de données est prise en charge par XML, permettant aux systèmes d'utiliser des bibliothèques et des cadres conformes à une norme, découplés de l'application.

XML est une spécification qui aborde la portée des exigences complexes dès la conception et est une norme définie par le W3C et prise en charge par tous les éditeurs de logiciels et plates-formes linguistiques concernés. En utilisant XML comme échange de données, les applications bénéficient automatiquement d'une réduction systématique du risque logiciel.

L'avenir de JSON

JSON est indéniablement là pour rester. Avec JavaScript comme plate-forme de développement la plus largement utilisée aujourd'hui, JSON est devenu le format d'échange de données le plus important. Pour les petits projets peu complexes, JSON convient parfaitement. Mais à mesure que nous nous efforçons de créer des applications plus grandes et meilleures pour l'avenir, la complexité générale de nos logiciels est destinée à augmenter. Avec les puissantes capacités de XML comme exemple, plusieurs groupes se sont efforcés d'inventer des normes similaires pour JSON.

Le défaut fondamental de JSON est son incapacité à fournir une norme générale pour la description normative des constituants logiques de ses documents.

Schéma JSON

En 2009, un groupe a lancé le schéma JSON ⁵ , qui est un vocabulaire pour annoter et valider des documents JSON. Le schéma JSON utilise la sémantique JSON pour définir un ensemble de règles et de contraintes pour les constituants des documents JSON, et plusieurs projets sur diverses plates-formes ont implémenté des bibliothèques qui prennent en charge la spécification du schéma JSON. Bien qu'il ne s'agisse pas encore d'une norme officielle, le projet de schéma JSON fournit une solution à un ensemble d'exigences similaire à la spécification de schéma XML. Avec le vocabulaire de schéma JSON, les développeurs peuvent définir les règles et contraintes logiques et structurelles des documents JSON. Le schéma peut ensuite être utilisé pour faciliter le traitement et la validation des documents JSON avec des bibliothèques découplées de l'application, réduisant ainsi le besoin de code non encapsulé à mélanger dans l'application. Avec le schéma JSON, un développeur peut choisir JSON comme format de son échange de données et répondre, de manière à limiter les risques, aux exigences complexes qui n'étaient pas adressables auparavant avec JSON seul.

Le projet de schéma JSON est un effort communautaire et, après une décennie de révisions, se présente comme la spécification dominante pour les schémas JSON. Bien qu'il ne soit pas encore un standard, la popularité du projet de schéma JSON indique le niveau d'intérêt pour une telle solution. Conceptuellement, la spécification du schéma JSON ressemble au schéma XML, mais une comparaison des deux révèle des différences entre leurs modèles, leurs capacités et leur sémantique. Par exemple, bien que le langage définisse un large éventail de propriétés pour contraindre les limites des types de valeurs JSON, ses nombreux attributs permettent l'expression de définitions de schéma auto-contradictoires.

Par exemple, l'extrait suivant définit un type "object" qui contient trois propriétés : "number" , "street_name" et "street_type" .

 { "type": "object", "properties": { "number": { "type": "number" }, "street_name": { "type": "string" }, "street_type": { "type": "string", "enum": ["Street", "Avenue", "Boulevard"] } } }

La définition d'un type "object" accepte des contraintes supplémentaires, dont l'une est "minProperties" . En modifiant la définition de type "object" ci-dessus avec un "minProperties": "4" , la définition devient absurde, car seules trois propriétés sont explicitement définies pour l'objet.

Le schéma JSON a un nombre considérablement grand et large de propriétés de contrainte, dont beaucoup sont essentielles pour confiner efficacement les documents JSON, et dont beaucoup se chevauchent. Avec des propriétés de contrainte dont la signification se chevauche, le vocabulaire du schéma JSON présente deux familles de défis :

1. Il nécessite une courbe d'apprentissage plus élevée de la part des développeurs, en raison du large vocabulaire et des nuances inhabituelles ou non conventionnelles de sa sémantique.
2. Il est plus difficile à mettre en œuvre pour les bibliothèques de validation, ce qui conduit à des solutions qui implémentent les zones grises différemment, ce qui entraîne des implémentations incohérentes.

Le langage de schéma XML lui-même n'est pas complètement exempt de permettre l'expression de définitions auto-contradictoires, mais elles sont beaucoup moins nombreuses et limitées. En fait, la spécification de schéma XML a été développée avec une attention particulière à la fois pour la facilité d'utilisation pour les développeurs ainsi que pour les bibliothèques implémentant la spécification. De plus, le projet de schéma JSON ne définit que la spécification du langage de schéma, mais il existe de nombreux projets communautaires qui implémentent cette spécification.

Le validateur de schéma JSON ⁶ est un projet populaire qui implémente un validateur de schéma JSON pour la plate-forme Java. En intégrant cette bibliothèque dans une application Java, l'application est capable d'affirmer la conformité de tous les documents JSON échangés. D'autres implémentations de la spécification de schéma JSON sont disponibles pour diverses plates-formes.

Pour la Banque européenne, utilisons le schéma JSON pour implémenter un schéma pour les messages JSON avec des identifiants de compte.

 { "$schema": "http://json-schema.org/draft-07/schema#", "definitions": { "swift": { "type": "object", "properties": { "type": { "type": "string", "pattern": "swift" }, "code": { "type": "string", "pattern": "(\\([0-9]{3}\\))?[0-9]{3}-[0-9]{4}" }, "required": ["type", "code"] } }, "iban": { "type": "object", "properties": { "type": { "type": "string", "pattern": "iban" }, "code": { "type": "string", "pattern": "[AZ]{2}\\d{2} ?\\d{4} ?\\d{4} ?\\d{4} ?\\d{4} ?\\d{0,2}" }, "required": ["type", "code"] } }, "ach": { "type": "object", "properties": { "type": { "type": "string", "pattern": "ach" }, "code": { "type": "string", "pattern": "\\w{1,17}" }, "routing": { "type": "string", "pattern": "\\d{9}" }, "required": ["type", "code", "routing"] } } } }

Ce schéma JSON définit les 3 types d'objet : "swift" , "iban" et "ach" . Il spécifie des modèles d'expressions régulières pour affirmer que les informations de compte ne sont pas invalides et déclare "type" et "code" comme propriétés requises pour chaque type, en plus de "routing" comme propriété requise pour le type "ach" . Avec ce schéma JSON, la Banque européenne peut valider son entrée JSON pour affirmer que le contenu du message est correct pour chaque interaction.

Le schéma JSON apporte de nombreuses fonctionnalités XML à JSON, mais il s'agit toujours d'un travail en cours. Bien qu'il s'agisse d'une excellente solution qui peut être utilisée pour couvrir les risques logiciels, la spécification du schéma JSON n'est pas parfaite. En raison de l'évolution informelle de sa langue, la langue a évolué dans une direction qui omet sans doute des caractéristiques importantes et contient des modèles d'expression structurels et logiques déroutants et non conventionnels. Par exemple, le langage de schéma n'a pas la capacité de définir des types abstraits, ce qui peut amener les développeurs à mettre en œuvre des solutions de contournement alambiquées qui entraînent un risque logiciel associé qui lui est propre. ⁷

Le projet de schéma JSON a apporté une richesse inestimable de contribution aux concepts derrière un langage de schéma pour JSON. Malgré les lacunes dans la clarté de sa sémantique, le langage de schéma JSON est une solution polyvalente qui apporte de nombreuses fonctionnalités de XML à JSON.

Pour plus d'informations sur la spécification du schéma JSON, reportez-vous à Présentation du schéma JSON.

JSONx

En 2014, un autre groupe a lancé le projet JSONx, qui exploite directement XML pour fournir une solution tout aussi puissante pour JSON. Le projet JSONx a été créé spécifiquement pour l'entreprise et définit le langage de définition de schéma JSON (JSD), qui est étroitement modélisé par la spécification de schéma XML. En utilisant le schéma XML comme modèle, le JSD définit des modèles structurels et logiques qui ressemblent beaucoup au langage de définition de schéma XML.

Pour l'exemple de la Banque européenne, utilisons le langage JSD pour implémenter un schéma pour les messages JSON avec des identifiants de compte.

 { "jx:ns": "http://www.jsonx.org/schema-0.3.jsd", "jx:schemaLocation": "http://www.jsonx.org/schema-0.3.jsd http://www.jsonx.org/schema-0.3.jsd", "message": { "jx:type": "object", "abstract": true }, "swift": { "jx:type": "object", "extends": "message", "properties": { "type": { "jx:type": "string", "pattern": "swift", "nullable": false }, "code": { "jx:type": "string", "pattern": "[AZ]{6}[A-Z0-9]{2}([A-Z0-9]{3})?", "nullable": false, "use": "required" } } }, "iban": { "jx:type": "object", "properties": { "type": { "jx:type": "string", "pattern": "iban", "nullable": false }, "code": { "jx:type": "string", "pattern": "[AZ]{2}\\d{2} ?\\d{4} ?\\d{4} ?\\d{4} ?\\d{4} ?[\\d]{0,2}", "nullable": false } } }, "ach": { "jx:type": "object", "properties": { "type": { "jx:type": "string", "pattern": "ach", "nullable": false }, "code": { "jx:type": "string", "pattern": "\\w{1,17}", "nullable": false }, "routing": { "jx:type": "string", "pattern": "\\d{9}", "nullable": false } } } }

À première vue, le schéma JSD est similaire dans son expression au schéma JSON. Une différence, cependant, est la sémantique concise du JSD par rapport au schéma JSON. Spécifique à cet exemple, le JSD place la propriété "use": "required" dans la définition spécifiée, tandis que le schéma JSON associe cette propriété à l'objet parent, exigeant que le nom des valeurs corresponde au nom de la définition de propriété. La contrainte "use": "required" n'est spécifiée que sur la propriété "code" de l'objet "swift" et omise des autres car "use": "required" est la valeur par défaut. Le langage JSD a été conçu en tenant compte de toutes ces nuances et offre une solution propre et intuitive pour l'expression des schémas JSON.

Dès le départ, une propriété distinctive du projet JSONx est son intention première de fournir clarté et utilité aux développeurs. Pour y parvenir, une fonctionnalité puissante du JSD est sa convertibilité en JSDx - le langage JSD peut être exprimé dans des fichiers JSON ainsi que dans des fichiers XML. Les deux formulaires sont traduisibles individuellement et offrent aux développeurs la possibilité d'utiliser des outils d'édition XML avancés pour faciliter la création de documents JSD à valider en direct et sans erreur.

Le schéma JSD ci-dessus peut être exprimé sous la forme JSDx suivante :

 <schema xmlns="http://www.jsonx.org/schema-0.3.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.jsonx.org/schema-0.3.xsd http://www.jsonx.org/schema-0.3.xsd"> <object name="swift"> <property name="code" xsi:type="string" pattern="[AZ]{6}[A-Z0-9]{2}([A-Z0-9]{3})?" nullable="false" use="required"/> </object> <object name="iban"> <property name="code" xsi:type="string" pattern="[AZ]{2}\d{2} ?\d{4} ?\d{4} ?\d{4} ?\d{4} ?\d{0,2}" nullable="false"/> </object> <object name="ach"> <property name="code" xsi:type="string" pattern="\w{1,17}" nullable="false"/> <property name="routing" xsi:type="string" pattern="\d{9}" nullable="false"/> </object> </schema>

La forme JSDx du JSD est puissante car elle fournit une spécification claire, auto-validante et à risque réduit pour la définition des schémas JSON.

Le langage JSD est conçu pour répondre aux problèmes de définitions auto-contradictoires et s'appuie sur des modèles standard pour l'expression des contraintes. Conçues de manière à ressembler étroitement au langage de définition de schéma XML (XSD), les déclarations de type JSD et les définitions de contraintes ressemblent étroitement aux structures équivalentes en XML. La spécification JSD(x) fournit une solution complète pour la définition des contraintes structurelles et logiques, et est auto-descriptive, fournissant une définition normative du langage JSD(x) exprimée dans le langage JSD(x) lui-même. Pour plus d'informations sur la spécification JSD(x), reportez-vous à JSON Schema Definition Language.

En plus du langage JSD(x), le projet JSONx fournit des implémentations de référence des processeurs et validateurs JSD(x) ainsi qu'une API de liaison de classe et un générateur de code pour la plate-forme Java. Avec l'API de liaison et le générateur, un développeur peut utiliser un schéma JSD(x) pour générer automatiquement des classes pour les définitions d'objet dans le schéma souhaité, qui peuvent être utilisées pour analyser et marshaler des documents JSON conformes au schéma. Les classes générées fournissent une liaison fortement typée entre le schéma et la plate-forme Java, représentant l'utilisation, les contraintes et les relations spécifiées dans le schéma. Avec des liaisons fortement typées au schéma, l'application réduit davantage le risque logiciel lié aux modifications futures qui pourraient entraîner des incompatibilités.

En tirant parti du compilateur de Java, les liaisons fortement typées identifient les incompatibilités avec les erreurs de compilation, réduisant efficacement à zéro le risque de bogues concernant le traitement des messages. Ce modèle d'ingénierie permet aux développeurs d'implémenter des modifications et de résoudre les incompatibilités rapidement et en toute confiance, sans avoir à compter sur le runtime pour trouver des bogues ou des cas d'échec, et surtout sans avoir à compter sur les utilisateurs pour tomber sur les bogues eux-mêmes. L'API de liaison est implémentée avec des annotations Java, ce qui permet à n'importe quelle classe d'être liée à un schéma JSD(x) avec des types forts, mais de manière légère. Les capacités de liaison et de génération de code fortement typées de JSONx prennent en charge l'intégralité de la spécification JSD(x), conçue spécifiquement pour répondre aux normes élevées des solutions d'entreprise.

Le framework JSONx a été créé pour les solutions d'entreprise et offre un haut niveau de qualité et d'utilité pour les systèmes complexes ainsi qu'une facilité d'utilisation et une validation des erreurs au moment de l'édition pour les développeurs.

Le moteur de liaison, le processeur et le validateur JSD(x) signalent une couverture de test de 87 %, permettant aux développeurs Java d'intégrer en toute confiance le cadre pour lier les schémas JSD(x) à leurs applications Java et encoder, décoder et valider les documents JSON. Pour en savoir plus sur le framework JSONx pour Java, reportez-vous à JSONx Framework pour Java.

Conclusion

En examinant de plus près l'histoire des tendances du Web et des logiciels ces dernières années, nous pouvons voir une relation étroite entre la prolifération de JavaScript et la popularité de JSON. De nombreux articles et billets de blog offrent une perspective limitée lors de la comparaison de JSON et XML, amenant les lecteurs à considérer XML comme obsolète, et laissant beaucoup d'entre eux ignorer les puissantes fonctionnalités qui peuvent les aider à améliorer l'architecture de leur logiciel, la résilience de leur logiciel au changement, et la qualité globale et stabilité du logiciel dans son ensemble. Avec une évaluation plus approfondie des forces et des faiblesses de chaque norme, les développeurs peuvent être en mesure de prendre de meilleures décisions pour leurs projets.

Comme la « catastrophe de divergence » avec HTML qui a conduit à l'invention de XML, un effet similaire est réalisé dans des bases de code complexes qui s'appuient sur JSON pour l'échange de données. La spécification JSON n'encapsule pas les fonctionnalités immédiates entourant l'échange de données, ce qui peut conduire à une fragmentation de la logique dans les couches supérieures de l'application. Avec XML, cependant, les développeurs peuvent repousser la complexité entourant l'échange de données vers les couches inférieures de l'application, ce qui permet de détecter les bogues plus tôt dans le cycle de vie de l'application. En particulier pour les langages compilés, en combinaison avec un cadre de liaison, les architectures qui reposent sur la liaison XML peuvent réduire à près de zéro le potentiel d'erreurs liées aux données. Pour l'entreprise, ce sont ces puissantes capacités de réduction systématique des risques logiciels qui font de XML le « Saint Graal de l'informatique ».

JSON est là pour rester, et plusieurs projets prennent de l'ampleur pour offrir les puissantes capacités de XML à JSON. Le projet de schéma JSON propose une spécification de schéma développée par la communauté qui s'est développée de manière organique pour prendre en charge un large éventail d'attributs et de modèles déclaratifs pour décrire et contraindre les documents JSON. Le projet JSONx fournit un langage de schéma de niveau entreprise qui ressemble beaucoup au langage de définition de schéma XML et propose les formats JSON et XML pour la spécification des documents de schéma JSON. Grâce à ces spécifications et cadres, les développeurs sont en mesure de réduire les risques logiciels liés aux exigences de couche supérieure entourant l'échange de données, telles que les contrats axés sur le consommateur, la gestion des versions de protocole, la validation de contenu, etc.

Les fonctionnalités avancées de XML ont été conçues pour atténuer le risque logiciel lié aux langages de balisage. Les cas d'utilisation avec JSON ne sont pas différents, et un langage de schéma est une solution éprouvée et éprouvée pour couvrir systématiquement le large éventail de risques logiciels entourant l'échange de données.

Les références

1. JSON contre XML (w3schools.com, décembre 2016)

2. Le succès mondial qu'est XML (W3C, juillet 2018)

3. W3C - Qu'est-ce qu'un schéma XML ? (W3C, octobre 2009)

4. Internet : une encyclopédie historique. Chronologie, tome 3, p. 130 (ABC-CLIO, 2005)

5. Schéma JSON (juillet 2008)

6. Validateur de schéma JSON (GitHub)

7. JsonSchema et sous-classement (Horne, mars 2016)