Le futur de JSON sera XML

JSON est un format de données textuel que nous croisons très régulièrement depuis quelques années, en particulier sur le Web. C’est un format si léger, facile à parser et manipulable en javascript que la plupart des APIs Web l’emploient pour exposer des données.

JSON est difficilement comparable au format XML – il est moins verbeux et ne permet pas d’avoir des attributs mais surtout, XML possède les “XML Schema” qui permettent de décrire la structure et le type de données contenu d’un fichier et ainsi de le valider.

Introducing JSON Schema

En 2009, kriszyp a commencé l’écriture d’une spécification IETF pour JSON Schema – une sorte de XSD pour JSON.

La spécification en est aujourd’hui à sa troisième version (toujours en draft) mais les implémentations sont nombreuses.

Pour écrire un schéma, il suffit de spécifier le type des données que l’on va trouver dans le fichier à valider parmi les types disponibles, le tout dans un fichier json :

  • string ;
  • number ;
  • integer ;
  • boolean ;
  • object ;
  • array ;
  • null ;
  • any.

Bien d’autres informations peuvent être ajoutées, un nom, une description, … ainsi que de nombreuses contraintes : pattern pour valider à l’aide d’une RegExp, minItems pour s’assurer de la présence d’au moins un certain nombre d’éléments dans un tableau, …

Prenons un exemple simple, le schema associé aux fichiers composer.json :

{
   "name": "Package",
   "type": "object",
   "properties": {
       "name": {
           "type": "string",
           "description": "Package name, including 'vendor-name/' prefix.",
           "required": true
       },
       "authors": {
           "type": "array",
           "description": "List of authors that contributed to the package. This is typically the main maintainers, not the full list.",
           "items": {
               "title": "A person",
               "type": "object",
               "properties": {
                   "name": {
                       "title": "Author's name",
                       "type": "string",
                       "required": true
                   },
                   "birthdate": {
                       "title": "Author's birth date",
                       "type": "string",
                       "pattern": "[0-9]{4}-[0-9]{1,2}-[0-9]{1,2}",
                       "required": true
                   }
               }
           },
           "minItems": 1
       }
   },
   "additionalProperties" : false
}

À l’aide d’une librairie PHP Open-Source, JSON Schema for PHP, on peut facilement tester les fichiers JSON :

$ echo "{}" | php cli.php
JSON does not validate. Violations:
[name] is missing and it is required

$ echo '{"name":"JSONValidatorZ"}' | php cli.php
The supplied JSON validates against the schema.

$ echo '{"name":"JSONValidatorZ", "authors": [{"name": "Benjamin", "toto":"tata"}, {"name": "Xavier"}]}' | php cli.php
JSON does not validate. Violations:
[authors[0].birthdate] is missing and it is required
[authors[1].birthdate] is missing and it is required

$ echo '{"name":"JSONValidatorZ", "authors": [{"name": "Benjamin", "birthdate": "1985-03-03"}, {"name": "Xavier", "birthdate": "1982-01-"}]}' | php cli.php
JSON does not validate. Violations:
[authors[1].birthdate] does not match the regex pattern [0-9]{4}-[0-9]{1,2}-[0-9]{1,2}

$ echo '{"name":"JSONValidatorZ", "authors": [{"name": "Benjamin", "birthdate": "1985-03-03"}, {"name": "Xavier", "birthdate": "1982-01-02"}]}' | php cli.php
The supplied JSON validates against the schema.

On trouve de nombreuses implémentations de validation dans différents langages, et concrètement, JSON Schema est déjà utilisé par plusieurs outils : Composer, par exemple qui valide le fichier composer.json avant de faire les traitements, ou encore Google API Discovery qui est un annuaire des APIs Google.

À savoir, il est aussi possible de valider le JSON Schema lui-même via un JSON Schema. Qui lui-même pourrait être validé par un JSON Schema.

Les autres drafts du moment

Les JSON References vont également rendre possible la découpe de nos fichiers JSON en plusieurs fichiers. En les définissant via le paramètre id et en les appellant via le paramètre $ref, il est possible de faire des références à des ressources externes.

Définition :

{
   "name": "Author",
   "id": "http://monsite.com/schemas/authors.json",
   …
}

Appel :

{
   "name": "Package",
   "type": "object",
   "properties": {
       "authors": {
           "type": "array",
           "items": {
               "title": "A person",
               "$ref": "http://monsite.com/schemas/authors.json"
       }
   }
}

Parlons aussi des JSON Pointers, qui s’annoncent comme un sorte de XPath pour JSON (mais ne pouvant pas sélectionner plusieurs éléments). Il s’agit d’une représentation textuelle identifiant une valeur au sein d’un document.

Pour un JSON comme suit :

{
   "foo": ["pony", "baz"],
   "": 0,
   "a/b": 1,
   "c%d": 2,
   "e^f": 3,
   "g|h": 4,
   "i\\j": 5,
   "k\"l": 6,
   " ": 7,
   "m~n": 8
}

Voici des exemples de pointeurs et leurs résultats. Vous noterez que / s’encode ~1 et ~, ~0.

  • "" : le document entier
  • "/foo" : ["pony", "baz"]
  • "/foo/0" : "pony"
  • "/" : `0`
  • "/a~1b" : `1`
  • "/c%d" : `2`
  • "/e^f" : `3`
  • "/g|h" : `4`
  • "/i\\j" : `5`
  • "/k\"l" : `6`
  • "/ " : `7`
  • "/m~0n" : `8`

Le format du futur ?

Standardisé en 2006, JSON ne cesse d’être un acteur majeur du Web. Le fait qu’il soit moins verbeux et plus limité que XML tout en étant assez souple pour la majorité des APIs Web lui permet de s’imposer dans de nombreux cas. Les différents drafts proposés aujourd’hui permettent la création de nouveaux outils autour de lui et en font un format plus robuste.

Il y a encore quelques défauts, comme l’impossibilité de mettre des commentaires, l’interdiction des virgules en fin de déclaration de liste, l’obligation de déclarer les clés avec des `”`… mais le futur de JSON est brillant.

blog comments powered by Disqus