JSON avec seulement un champ

a marqué ce sujet comme résolu.
Auteur du sujet

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…

Édité par cbourree

Qui ne pète ni ne rote est voué à l’explosion.

+0 -0

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.

Édité par viki53

Mes tutos — Développeur JS (front principalement) — Consultant qualité, ergonomie et UX

+0 -3

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

A-312

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 ?

Mes tutos — Développeur JS (front principalement) — Consultant qualité, ergonomie et UX

+0 -0
Auteur du sujet

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 ?

Qui ne pète ni ne rote est voué à l’explosion.

+0 -0

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 ?

Mes tutos — Développeur JS (front principalement) — Consultant qualité, ergonomie et UX

+0 -0
Auteur du sujet

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 ;)

Qui ne pète ni ne rote est voué à l’explosion.

+0 -0

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". :(

Édité par A-312

✈️ // 🐺 Ami des loups // 🎮 Coding Game // 🐤 Twitter @A312_zds // :B // L’hiver vient // @**A-312** pour me ping

+1 -0

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.

Mes tutos — Développeur JS (front principalement) — Consultant qualité, ergonomie et UX

+1 -0

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 :)

A graphical interface is like a joke: if you have to explain it, that’s shit.

+0 -0

Est-ce que une API qui renvoie un truc aussi simple que

"Salut"

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

cbourree

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).

Vous aimez le frontend ? Il y a un tas de petites tâches faciles si vous voulez contribuer à ZdS : https://github.com/zestedesavoir/zds-site/issues?q=is%3Aissue+is%3Aopen+label%3AC-Front

+1 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte