JSON avec seulement un champ

Bonjour,

Avec un ami on arrive pas à se mettre d’accord ni réellement à se justifier. Est-ce que une API qui renvoie un truc aussi simple que

1

"Salut"

Avec un type MIME json renvoie effectivement un vrai fichier json ?

En effet selon wikipédia

Un document JSON ne comprend que deux types d’éléments structurels :

des ensembles de paires « nom » (alias « clé ») / « valeur » ;

des listes ordonné de valeurs

Le fichier semble ne pas correspondre à cette définition. Mais en même temps tout à fait lisible comme JSO? par Mozilla…

Non, car un parseur JSON ne comprendra pas, ce n’est pas un JSON valide.

Essaie JSON.parse('Salut'), tu verras une belle erreur s’afficher dans ta console.

Ok merci <3

Mais au contraire si tu essayes : JSON.parse('"Salut"') === "Salut"

JSON est un format récursif, les « atomes » (chaines, entiers, booléens, null) sont des valeurs JSON valides au même titre qu’une liste ou un dictionaire (« object »).

https://www.json.org/

Du coup j’ai pas compris, on parle d’une chaîne brute ou au format JSON (donc avec les quotes affichées) ?

Parce que si c’est une chaîne au bon format, effectivement c’est valide donc le type MIME fait sens.

C’est quoi ton cas d’usage exactement ?

Mon cas d’usage est surtout spirituel… On est entrain de faire notre première vraie API et on se demandait si sur un get /currentLevel il valait mieux renvoyer

1
2
3

{
  "level": 1
}

ou juste 1

Qu’en pensez-vous du coup ?

Si tu n’as vraiment qu’une valeur à renvoyer (ce qui est déjà très rare), inutile d’envoyer un objet complet.

Mais si tu n’as qu’une valeur, pourquoi ne pas l’incorporer directement à un autre endpoint ?

Car les valeurs n’ont pas un besoin de rafraichissement identiques. Et que aller chercher/calculer chacune de ses la donnée dans la blockchain est relativement couteux. Mais j’avoue ne pas vraiment m’être posé la question

Pour une api, j’aime bien quelques choses comme ça :

1
2
3
4
5
6

{
    sucess: true,
    data: {
        "level": 1
    }
}

1
2
3
4

{
    sucess: false,
    error: "missing_argument"
}

Ça évite une gestion au try { } catch { } du retour… Sinon on ne sait pas si :

• C’est une erreur de notre requête;
• Une erreur du serveur qui n’a pas été indique en response status code  ;
• De la connexion/proxy ;
• Si c’est la valeur directe ou une erreur.

Si j’ai mon header qui demande du json ou je demande précisément du json, je veux du json !

1

Accept: application/json

ou :

1

GET /currentLevel.json

EDIT : J’avais cliqué sur "envoyer" et non "aperçu".

Le champ success ne sert à rien, autant avoir un champ error à null si il n’y a pas d’erreur. Si le status code vaut 2XX, le champ error doit être null.

Tant que le status code est respecté, des fois on a une API qui retourne une erreur sans code d’erreur… Ou de 3 façons différentes, c’est assez lourd à utiliser.

Autant ne pas avoir de champ error s’il n’y en a pas, tant qu’à faire.

Et respecter les status codes est la base de toute API REST digne de ce nom, ça permet généralement de se faire une idée du type d’erreur sans même avoir à parser la réponse.

"error" permet de renseigner l’erreur dans certain cas ça peut être utile, si la requête est bonne, les arguments présents mais pour X raison, les données ne peuvent pas être récupérer pour l’élément en question.

Hello,

Pour en revenir à la question d’origine (1 ou {"level":1} ?), je partirais plus sur un objet également, pas seulement pour retourner une erreur si nécessaire (encore que pour moi, ce cas mériterait presque un traitement spécial pour retourner un statut adéquat en fonction du problème), mais aussi dans un souci d’évoluabilité : actuellement, ton API retourne simplement une valeur, mais si par la suite tu souhaites ajouter des valeurs au JSON retourné par l’endpoint (par exemple, une liste de quêtes que l’utilisateur doit mener à bien pour passer au niveau suivant), il faut pouvoir s’assurer que les applis qui le consomment puissent continuer de fonctionner. Si c’est un objet dès le départ, les anciennes versions ignoreront simplement les nouvelles valeurs ; si tu mets une simple chaîne de caractères et que l’endpoint retourne brutalement un objet, elles ne comprendront plus ce qu’elles reçoivent et ne fonctionneront plus. À moins de créer une v2 de l’API, mais ce serait dommage

Dans tous les cas, si tu fais évoluer ton API, tu proposes les versions à différents endpoints pour pas casser toutes les applications qui utilisent ton API.

Parfaitement valide, oui.

La spec est même traduite en français : http://www.json.org/json-fr.html

Chacun des éléments de base (en image sur cette page) est un objet JSON valide : object, array, value (et donc string, number).