Closed mgageo closed 1 year ago
Bonjour @mgageo,
C'est le code de statut que nous avons choisi lorsque le résultat la requête de l'API ne renvoie rien sans pour autant être une erreur. Par exemple, l'API qui renvoie le territoire du centre de la carte. Auparavant, l'on retournait une erreur 404 (not found), pas très réjouissant lorsque l'on ouvre la console du navigateur. Ce n'est pas à proprement parlé une erreur, juste une absence de donnée sur ce lieu (204 > no content).
Côté frontend, cela nous permet de gérer plus proprement les appels d'API avec l'ajout d'une condition if (data) ...
.
C'est bien entendu discutable.
Répondre avec un fichier json vide me semble préférable, considérer les erreurs de la couche "transport" comme une réponse correcte pour la couche "application" est un peu douteux d'un point de vue conceptuel.
Merci pour ce retour, si je comprends bien, la proposition serait de renvoyer une réponse avec statut 200 avec un json vide (ex: []
ou {}
) ?
Le json vide est pour moi la moins mauvaise solution, une réponse en json avec le même format serait encore préférable {"type":"FeatureCollection","features":[]} Sur une erreur de la couche "transport", je réessaye avant de passer à la couche "application".
API revues pour renvoyer des données "vides" au lieu des réponses vides avec code 204
[]
pour les listes{}
pour les dictionnaires et les Features{"type":"FeatureCollection","features":[]}
pour les geojson featurecollections
Sur des requêtes, la réponse n'est plus un fichier json vide mais un http 204. Ce comportement est définitif ?