Convertir du JSON en classes C# immédiatement exploitables peut se faire à la main, mais c’est ennuyeux, long et il est facile de faire des erreurs. Une petite astuce très simple pour aujourd’hui : QuickType.
JSON
JSON est un format de sérialisation plus que populaire. Pour des tas de raisons assez peu rationnelles à mon sens, mais c’est ça la mode, il est devenu plus “hype” que XML tout en faisant la même chose et en étant presque aussi verbeux. La mode a ses mystères que la raisons ne saurait connaître aurait pu dire le poète…
Quoi qu’il en soit JSON c’est bien, efficace, ça marche, et c’est beaucoup utilisé. D’excellentes raisons de s’en servir. Mais aussi d’être confronté qu’on le veuille ou non à ce format.
Donc JSON c’est comme XML, des balises, des attributs, des imbrications pour les collections, etc. La différence majeure c’est un peu la même qu’entre Pascal Objet et Java, dans l’un on écrit en toutes lettres Begin/End pour un bloc de code, dans l’autre on utilise des accolades { et } et le développeur croit avoir pondu un code plus court, exploitant ainsi la pensée magique à l’œuvre chez l’humain de base.
Sauf que les fameuses accolades qu’on dit “américaines” ne portent pas ce nom pour rien : elles sont accessibles directement sur un clavier QWERTY mais réclament toute une gymnastique sur un clavier AZERTY, un peu dans le style de ce qui faisait la moquerie de la combinaison CTRL-ALT-DEL. Mais ce dernier est mal car datant d’une époque où les français avaient encore une âme et un jugement sur les excentricités yankies, les accolades américaines c’est bien car ça date de l’époque où l’Aile ou La Cuisse est devenu un nanar, Coluche est mort et McDo a enfin réussi à envahir le pays devenu depuis une province des USA. En gros rappelez-vous quand dans notre monde moderne, tout ce qui est américain datant de moins de 30 ans est le bien et que le reste est généralement le mal, voire le mal absolu. C’est simple à piger en fait.
Du coup, il faut sérialiser en JSON pour être cool.
Or .NET avait plutôt été pensé pour la sérialisation XML. Ce qui était logique. Et quelques attributs bien placés sur une classe existante suffisaient à pouvoir la sérialiser / désérialiser sans trop de soucis.
Mais comme comme rien n’est parfait, JSON est alors venu s’insérer dans les quelques failles du support XML de .NET (un peu lent et ne gérant pas bien certains cas, null, références circulaires…). Et il s’avère surtout qu’un jour est né la fameuse librairie NewtonSoft.JSON. Rapide, performante, couvrant plus facilement les collections, les imbrications, les références circulaires, etc.
Ainsi est né l’avènement de JSON même sous .NET.
Sérialiser est une formalité, en XML comme en JSON, cela produit un fichier texte lisible facilement et transmissible via HTTP ou TCP par exemple. Et c’est devenu l’une des façons de s’en servir la plus fréquente.
Mais à la réception… ça se corse un peu.
Désérialiser JSON
XML ou JSON sont des formats texte décrivant des objets avec leurs attributs et leurs valeurs. Désérialiser est donc une opération consistant à instancier des objets en mémoire.
Autant lorsqu’on sérialise le problème ne se pose pas (puisqu’on sérialise un objet existant, son existence ne pose pas de question), autant lorsqu’on désérialise se pose la question de l’existence des classes qui vont donner naissances aux fameuses instances, le résultat de la réhydratation.
Au sein d’une même application utilisant JSON ou XML comme support de sauvegarde (état de l’application, préférences utilisateurs…) la question ne se pose toujours pas, les classes sérialisées existent donc et sont réutilisées pour désérialiser.
En revanche le problème devient plus épineux lorsqu’une application reçoit de l’extérieur des données exprimées en JSON. Ces données n’ont pas forcément d’équivalent sous forme de classe dans le code. Et c’est un cas très fréquent.
Donc cela est souvent nécessaire.
Une étape essentielle s’impose alors : transformer du JSON en classe(s) pour enfin pouvoir désérialiser ce dernier…
Le faire à la main est possible comme je le disais mais c’est peu pratique et cela laisse la porte ouverte à des erreurs.
Création de classes automatique
Le plus simple serait de partir d’un exemple de texte JSON et de le traduire en une classe C# (ou autre) puisque JSON tout comme XML est auto-descriptif. D’autant que les petits objets sont simples à convertir à la main mais que les utilisations de JSON dans les web services se fait plutôt par le biais de réponses très verbeuses. Prenez les événements Github par exemple,c’est presque une vingtaine de classes dont certaines avec des dizaines de propriétés.
Il faut un outil automatique pour cela.
QuickType
Il existe déjà un site web json2csharp.com dont j’ai déjà parlé qui remplit à merveille cet office. Mais il est très simple et ne supporte que C#.
Il y a aujourd’hui un service beaucoup plus complet qu’on trouve sur https://quicktype.io
Cela ressemble à ça :
Avec des petits plus notamment le choix du langage comme C#, TypeScript ou Java. Mais on peut aussi extraire le schéma ce qui peut être très utile (validation de données par exemple avant réhydratation).
Mieux le code généré peut être légèrement adapté selon qu’on le veuille plus compact, fidèle à C# 5 ou 6, qu’on préfère des arrays ou des List<T> etc.
Conclusion
Rien de bien extravagant dans QuickType, mais comme JSON est incontournable, autant utiliser les bons outils qui font gagner le plus de temps (pour déguster son McDo tranquillement) !
Les canicules sont terminées mais on oublie souvent qu’il faut en hiver aussi beaucoup s’hydrater. C’était le conseil santé du jour (sponsorisé par NewtonSoft.JSON et par Coca-Cola en associant avec la World Company).
Hydratez-vous et Stay Tuned !