JSON doit-il inclure des valeurs nulles [fermé]

89

Je crée une API qui renvoie les résultats au format JSON. Existe-t-il une meilleure pratique actuelle pour savoir si nous devons inclure des clés dans le résultat lorsque la valeur est nulle? Par exemple:

{
    "title":"Foo Bar",
    "author":"Joe Blow",
    "isbn":null
}

ou

{
    "title":"Foo Bar",
    "author":"Joe Blow"
}

Comme le second est plus petit, je me penche vers ce style, mais je ne sais pas s'il existe un style préféré ou non. Du point de vue du client, il semble que les deux styles seraient fonctionnellement équivalents. Des avantages ou des inconvénients à chacun?

— jjathman
source

6

Il est impossible de répondre correctement à cela. La bonne réponse dépend des exigences de l'application. L'OP a simplement sélectionné la réponse qui correspond à ses besoins. Si votre application doit être en mesure de faire la distinction entre savoir si "isbn" est nul et si "isbn" peut ne pas avoir été envoyé depuis le serveur pour une autre raison, vous devez l'inclure.

— Jacob

@Jacob Bien que je ne l'ai pas dit, mon intention avec cette question était que le JSON "complet" représentant la réponse était renvoyé. Lorsqu'un client peut supposer qu'il ne semble y avoir aucune différence fonctionnelle entre les deux approches. Si l'API ne retournait pas sélectivement les clés / valeurs, alors oui, cela ferait une grande différence quelle approche a été adoptée.

— jjathman le

l'avantage de la première représentation est que le schéma de l'objet est préservé, la présence de la propriété n'est pas ambiguë en fonction des données. dans le second format, ces informations sont perdues. Les spécifications JSON en tant que telles n'imposent aucun des formats AFAIK

— Surya Pratap

32

Le second économisera une petite quantité de bande passante, mais si cela était un problème, vous utiliseriez également des tableaux indexés au lieu de remplir le JSON avec des clés. De toute évidence, ["Foo Bar","Joe Blow"]c'est beaucoup plus court que ce que vous avez maintenant.

En termes de convivialité, je ne pense pas que cela fasse de différence. Dans les deux cas, if(json.isbn)passera au else. Il n'est généralement pas nécessaire de faire la distinction entre null(aucune valeur) et undefined(aucune valeur donnée).

— Niet the Dark Absol
source

7

+1 pour Il n'est généralement pas nécessaire de faire la distinction entre null (pas de valeur) et indéfini (pas de valeur donnée). Il y a même un opérateur pratique pour cela != null(prévu non strict)

— Esailija

Le seul cas auquel je puisse penser serait de tester si un navigateur prend en charge un certain type d'événement. Par exemple, if( typeof onbeforepaste == "undefined")pour voir si onBeforePasteest pris en charge. Même dans ce cas, cela ne fait aucune différence puisque vous pouvez attribuer des événements autant que vous le souhaitez (ils ne feront rien s'ils ne sont pas pris en charge).

— Niet the Dark Absol

6

En termes de sauvegarde des octets transférés, la compression est beaucoup plus importante que des éléments tels que les tableaux indexés. web-resource-optimization.blogspot.no/2011/06/… Assurez-vous que c'est la première chose que vous faites. Dans la plupart des cas, ajouter des éléments tels que des tableaux indexés en plus est ce que j'appellerais une optimisation prématurée. Sauf si vous envoyez de GRANDES quantités de données. Cela nécessite également une analyse supplémentaire, ajoutant plus de complexité à votre application. Gzipping est effectué de manière transparente par le navigateur. (en supposant que le client est un navigateur)

— Martin Hansen

3

Avec HTTPS devenant la norme du jour (du moins pour les applications avec une grande base d'utilisateurs), la compression est un jeu d'enfant. Voir en.wikipedia.org/wiki/CRIME_%28security_exploit%29

— Gaurav Vaish

6

Je voudrais en fait -1 pour "Il n'est généralement pas nécessaire de faire la distinction entre null" si j'avais une réputation. De 2 raisons: 1. des raisons de distinguer existent et elles ne sont pas rares 2. la meilleure pratique est de toujours avoir des valeurs «bien définies», ce qui signifie toujours éviter toute ambiguïté - 2 significations d'une valeur est toujours mauvaise - cela devrait être assez clair.

— Srneczek

80

Je suis fan de toujours inclure explicitement null car cela a un sens. L'omission d'une propriété laisse une ambiguïté.

Tant que votre protocole avec le serveur est convenu, l'un des éléments ci-dessus peut fonctionner, mais si vous transmettez des valeurs nulles depuis le serveur, je pense que cela rendra vos API plus flexibles plus tard.

Il faut également mentionner que la fonction hasOwnProperty de javascript vous donne un aperçu supplémentaire.

/* if true object DOES contain the property with *some* value */
if( objectFromJSON.hasOwnProperty( "propertyName" ) )

/* if true object DOES contain the property and it has been set to null */
if( jsonObject.propertyName === null )

/* if true object either DOES NOT contain the property
   OR
   object DOES contain the property and it has been set to undefined */
if( jsonObject.propertyName === undefined )

— rushkeldon
source

3

Exactement, plus de personnes doivent comprendre la différence entre "", null et undefined. La réponse à cette question dépend des besoins des utilisateurs.

— Jacob

13

+1. La personne à l'autre bout (qui a écrit le code) sera mieux servie par des valeurs explicites. Ils

— n'écrivent

2

Notez que la vérification par rapport à null ne fonctionne pas avec ==, === est obligatoire (car undefined == null)!

— Tommy

exactement la première partie de la réponse acceptée est si fausse ...

— Srneczek

J'écrirais "propertyName" in objectFromJSONau lieu de objectFromJSON.hasOwnProperty("propertyName"). De plus, si vous insistez pour utiliser, hasOwnPropertyécrivez Object.prototype.hasOwnProperty.call(objectFromJSON, "propertyName")par sécurité.

— Aadit M Shah

22

En JavaScript, cela nullsignifie quelque chose de très différent de undefined.

Votre sortie JSON doit refléter ce qui est utilisé et requis par votre application dans le contexte spécifique d'utilisation des données JSON.

— Brad
source

5

Il n'y a pas de "non défini" dans JSON, donc je pense qu'il demande seulement s'il faut inclure des propriétés "vides" ou non - {"prop":undefined}est différent de {}.

— Bergi

D'accord, j'essaie d'expliquer que du côté récepteur, s'il recherche une propriété spécifique à mettre à null, ce ne sera pas le cas. Il sera indéfini s'il est omis.

— Brad

11

Vous devez absolument l'inclure s'il est nécessaire de faire la distinction entre nullet undefinedpuisque ceux-ci ont deux significations différentes en Javascript. Vous pouvez penser nullque la propriété est inconnue ou dénuée de sens, et undefinedque la propriété n'existe pas.

D'un autre côté, s'il n'est pas nécessaire que quiconque fasse cette distinction, allez-y et laissez-la de côté.

— Paul
source

0

Je pense que ce n'est pas une différence lorsque vous utilisez le JSON comme données derrière l'expérience utilisateur.

La différence apparaît dans les fichiers de configuration JSON, lorsqu'un utilisateur doit modifier quelque chose à la main. Lorsque vous utilisez le premier exemple, vous donnez à l'utilisateur un indice sur la configuration.

— Alexey Kachalov
source

1

Pourriez-vous s'il vous plaît préciser votre réponse en ajoutant un peu plus de description de la solution que vous fournissez?

— abarisone