Quel est le bon REST code de réponse pour une demande valide mais des données vides?

Question

Par exemple, vous exécutez une demande GET pour users/9 mais aucun utilisateur n’a l’ID n ° 9 . Quel est le meilleur code de réponse?

• 200 OK
• 202 Accepté
• 204 Pas de contenu
• 400 mauvaise demande
• 404 introuvable

Answer 1

TL; DR: Utiliser 404

Voir ce blog . Cela l'explique très bien.

Résumé des commentaires du blog sur 204:

1. 204 No Content n'est pas très utile en tant que code de réponse pour un navigateur (bien que, selon la spécification HTTP, les navigateurs aient besoin de le comprendre comme un code de réponse 'ne changez pas la vue').
2. 204 No Contentest cependant, très utile pour les services Web ajax qui peuvent vouloir indiquer le succès sans avoir à retourner quelque chose. (Surtout dans les cas comme DELETE ou POSTs qui ne nécessitent pas de retour d'information).

La réponse à votre question est donc d'utiliser 404 dans votre cas. 204 est un code de réponse spécialisé que vous ne devriez pas souvent retourner dans un navigateur en réponse à une GET.

Les autres codes de réponse encore moins appropriés que 204 et 404:

1. 200 devrait être renvoyé avec le corps de tout ce que vous avez récupéré avec succès. Non approprié lorsque l'entité que vous récupérez n'existe pas.
2. 202 est utilisé lorsque le serveur a commencé à travailler sur un objet mais que celui-ci n'est pas encore prêt. Certainement pas le cas ici. Vous n'avez pas commencé ni ne commencerez la construction de l'utilisateur 9 en réponse à une demande GET. Cela brise toutes sortes de règles.
3. 400 est utilisé en réponse à une requête HTTP mal formatée (par exemple des en-têtes http mal formés, des segments mal ordonnés, etc.). Ce sera presque certainement géré par le cadre que vous utilisez. Vous ne devriez pas avoir à vous en occuper sauf si vous écrivez votre propre serveur à partir de rien. Edit: Les RFC les plus récentes permettent maintenant d’en utiliser 400 pour les requêtes sémantiquement invalides.

Les description des codes de statut HTTP de Wikipedia sont particulièrement utiles . Vous pouvez également voir les définitions dans le document HTTP/1.1 RFC2616 à l'adresse www.w3.org

Answer 2

Je m'oppose fermement à 404 en faveur de 204 ou 200 avec des données vides.

La demande a été reçue et traitée correctement - elle a déclenché le code de l'application sur le serveur. On ne peut donc pas vraiment dire qu'il s'agissait d'une erreur du client. Par conséquent, toute la classe de codes d'erreur du client (4xx) ne convient pas.

Plus important encore, 404 peut se produire pour diverses raisons techniques. Par exemple. l'application étant temporairement désactivée ou désinstallée sur le serveur, problèmes de connexion proxy, etc. Par conséquent, le client ne peut pas faire la distinction entre un 404 qui signifie "jeu de résultats vide" et un 404 qui signifie "le service est introuvable, réessayez plus tard". 

Cela peut être fatal: imaginez un service de comptabilité dans votre entreprise répertoriant tous les employés qui bénéficient d’un bonus annuel. Malheureusement, la seule fois où il est appelé, il renvoie 404. Cela signifie-t-il que personne ne doit recevoir de bonus ou que l'application est actuellement hors service pour un nouveau déploiement? 

-> Pour les applications soucieuses de la qualité de leurs données, 404 est donc quasiment inutilisable.

En outre, de nombreux frameworks clients répondent à un 404 en lançant une exception sans poser de questions. Cela oblige le développeur client à intercepter cette exception, à l'évaluer, puis à décider en fonction de celle-ci de la consigner ou de la consigner sous forme d'erreur corrigée, par exemple. un composant de surveillance ou si l'ignorer. Cela ne me semble pas joli non plus.

Le seul avantage de 404 sur 204 est qu'il peut renvoyer une entité de réponse pouvant contenir des informations sur la raison pour laquelle la ressource demandée n'a pas été trouvée. Mais si cela est vraiment pertinent, vous pouvez également envisager d'utiliser une réponse 200 OK et concevoir le système de manière à permettre des réponses d'erreur dans les données de charge utile. Il est également possible d’utiliser la charge utile de la réponse 404 pour renvoyer des informations structurées à l’appelant. S'il reçoit par exemple une page html au lieu de XML ou JSON qu’il peut analyser, c’est un bon indicateur que quelque chose de technique a mal tourné au lieu d’une réponse "aucun résultat" qui peut être valide du point de vue de l’appelant. Ou on pourrait utiliser un en-tête de réponse HTTP pour cela.

Néanmoins, je préférerais un 204 ou 200 avec une réponse vide si. De cette façon, le statut de l'exécution technique de la demande est séparé du résultat logique de la demande. 2xx signifie "exécution technique ok, voici le résultat, résolvez-vous". 

Je pense que dans la plupart des cas, il devrait être laissé au client de décider si un résultat vide est acceptable ou non. En renvoyant 404 malgré une exécution technique correcte, le client peut décider de considérer les cas comme des erreurs qui ne sont tout simplement pas des erreurs.

Une autre analogie rapide: renvoyer 404 pour "aucun résultat trouvé" revient à lancer une exception DatabaseConnectionException si une requête SQL n'a renvoyé aucun résultat. Cela peut faire le travail, mais il y a beaucoup de causes techniques possibles qui génèrent la même exception qui serait alors prise pour un résultat valide.

Answer 3

Au début, je pensais qu'un 204 aurait un sens, mais après les discussions, je pense que le 404 est la seule réponse correcte. Considérez les données suivantes:

Utilisateurs: John, Peter

METHOD  URL                      STATUS  RESPONSE
GET     /users                   200     [John, Peter]
GET     /users/john              200     John
GET     /users/kyle              404     Not found
GET     /users?name=kyle`        200     []
DELETE  /users/john              204     No Content

Un peu de fond:

1. la recherche renvoie un tableau, il n'y a tout simplement aucune correspondance, maisit a le contenu suivant: un tableau vide. 

2. 404 est bien sûr plus connu pour les URL qui ne sont pas supportées par le serveur demandé, mais une ressource manquante est en fait la même.
   Même si /users/:name est associé à users/kyle, l'utilisateur Kyle n'est pas une ressource disponible, de sorte qu'un 404 s'applique toujours. Ce n'est pas une requête de recherche , C'est une référence directe par une URL dynamique, donc elle est 404.

En tout cas, mes deux centimes :)

Answer 4

Dans les projets précédents, j'avais utilisé 404. S'il n'y a pas d'utilisateur 9, l'objet n'a pas été trouvé. Par conséquent, 404 Not Found est approprié.

Pour objet existe, mais il n'y a pas de données, 204 Aucun contenu ne serait approprié. Je pense que dans votre cas, l'objet existe pas existe bien.

Answer 5

Si l'on s'attend à ce que la ressource existe, mais qu'elle soit peut-être vide, je dirais qu'il serait peut-être plus facile d'obtenir simplement 200 OK avec une représentation indiquant que l'élément est vide.

Donc je préférerais que les choses retournent 200 OK avec {"Items": []} plutôt que 204 sans rien du tout, car de cette manière une collection avec 0 items peut être traitée plus d'article dedans.

Je laisserais simplement le 204 No Content for PUTs et DELETEs, où il se pourrait qu'il n'y ait aucune représentation utile.

Dans le cas où/thing/9 n'existe pas vraiment, un 404 est approprié.

Answer 6

Selon w3 post,

200 OK 

La demande a réussi. Les informations renvoyées avec la réponse dépendent de la méthode utilisée dans la demande.

202 Accepté

La demande a été acceptée pour traitement, mais le traitement n'est pas terminé.

204 Pas de contenu

Le serveur a répondu à la demande mais n'a pas besoin de renvoyer un corps d'entité et peut vouloir renvoyer des métainformations mises à jour.

400 mauvaise demande 

La requête n'a pas pu être comprise par le serveur en raison d'une syntaxe mal formée. Le client NE DEVRAIT PAS répéter la demande sans modifications.

401 Non autorisé 

La demande nécessite une authentification de l'utilisateur. La réponse DOIT inclure un champ d'en-tête WWW-Authenticate 

404 Introuvable

Le serveur n'a rien trouvé qui corresponde à l'URI de demande. Aucune indication n'est donnée quant à savoir si la condition est temporaire ou permanente

Answer 7

Pour résumer ou simplifier, 

2xx: Données facultatives: URI bien formé: Les critères ne font pas partie de l'URI: Si le critère est facultatif, vous pouvez le spécifier dans @RequestBody et @RequestParam doit conduire à 2xx. Exemple: filtrer par nom/statut

4xx: Données attendues: URI mal formé: Les critères font partie de l'URI: Si le critère est obligatoire et ne peut être spécifié que dans @PathVariable, il doit alors conduire à 4xx. Exemple: recherche par identifiant unique.

Ainsi pour la situation demandée: "Utilisateurs/9" serait 4xx (éventuellement 404) Mais pour "utilisateurs? Nom = superman" devrait être 2xx (éventuellement 204)

Answer 8

Il y a deux questions posées. Un dans le titre et un dans l'exemple. Je pense que cela a en partie conduit à la controverse quant à savoir quelle réponse est appropriée.

Le titre de la question concerne les données vides. Les données vides sont toujours des données mais ne sont pas identiques à aucune donnée. Ceci suggère donc de demander un ensemble de résultats, c'est-à-dire une liste, peut-être à partir de /users. Si une liste est vide, il s'agit toujours d'une liste, c'est pourquoi un 204 (sans contenu) est le plus approprié. Vous venez de demander une liste d'utilisateurs et vous en avez reçu une, il se trouve qu'il n'y a aucun contenu. 

L'exemple fourni à la place concerne un objet spécifique, un utilisateur, /users/9. Si l'utilisateur n ° 9 n'est pas trouvé, aucun objet utilisateur n'est renvoyé. Vous avez demandé une ressource spécifique (un objet utilisateur) et vous ne l'avez pas reçu car elle n'a pas été trouvée. Un 404 est donc approprié. 

Je pense que la solution consiste à utiliser la réponse de la manière attendue sans ajouter d’instruction conditionnelle, puis à utiliser un 204 sinon à utiliser un 404.

Dans mes exemples, je peux parcourir une liste vide sans vérifier si elle contient du contenu, mais je ne peux pas afficher les données d'objet utilisateur sur un objet null sans casser quelque chose ou ajouter une vérification pour voir si elle est nulle.

Vous pouvez bien sûr renvoyer un objet en utilisant le modèle d'objet NULL si cela vous convient, mais il s'agit d'une discussion pour un autre thread.

Answer 9

Ce que les réponses existantes n’expliquent pas, c’est que le fait d’utiliser des paramètres de chemin ou de requête fait une différence.

• Dans le cas de paramètres de chemin, le paramètre fait partie du chemin de la ressource. Dans le cas de /users/9, la réponse devrait être 404 car cette ressource n'a pas été trouvée. /users/9 est la ressource et le résultat est unaire ou une erreur, il n'existe pas. C'est pas une monade.
• Dans le cas de paramètres de requête, le paramètre ne fait pas partie du chemin de la ressource. Dans le cas de /users?id=9, la réponse doit être 204 car la ressource /users a été trouvée mais elle ne peut renvoyer aucune donnée. La ressource /users existe et le résultat est n-aire, elle existe même si elle est vide. Si id est unique, ceci est une monade.

Le choix d'utiliser des paramètres de chemin d'accès ou des paramètres de requête dépend du cas d'utilisation. Je préfère les paramètres de chemin pour les arguments obligatoires, normatifs ou d'identification et les paramètres de requête pour les arguments facultatifs, non normatifs ou d'attribution (comme la pagination, les paramètres régionaux de classement et d'autres éléments). Dans une API REST, j'utiliserais /users/9 et non pas /users?id=9, en raison notamment de l'imbrication possible pour obtenir des "enregistrements enfants" comme /users/9/ssh-keys/0 pour obtenir la première clé ssh publique ou /users/9/address/2 pour obtenir la troisième adresse postale.

Je préfère utiliser 404. Voici pourquoi:

• Les appels à des méthodes unaires (1 résultat) et n-aire (n résultats) ne doivent pas varier sans raison valable. J'aime avoir les mêmes codes de réponse si possible. Le nombre de résultats attendus est bien sûr une différence, supposons que le corps soit un objet (unaire) ou un tableau d’objets (n-aire).
• Pour n-aire, je renverrais un tableau, et au cas où il n'y aurait pas de résultats, je ne renverrais aucun ensemble (aucun document), je renverrais un ensemble vide (document vide, comme un tableau vide en JSON ou un élément vide en XML). ). C’est-à-dire qu’il reste 200 mais avec zéro enregistrement. Il n'y a aucune raison de mettre cette information sur le fil autre que dans le corps.
• 204 est comme une méthode void. Je ne l'utiliserais pas pour GET, mais uniquement pour POST, PUT et DELETE. Je fais une exception dans le cas de GET où les identifiants sont des paramètres de requête et non de chemin.
• Ne pas trouver l'enregistrement est comme NoSuchElementException, ArrayIndexOutOfBoundsException ou quelque chose du genre, causé par l'utilisation par un client d'un identifiant qui n'existe pas, c'est donc une erreur du client.
• Du point de vue du code, obtenir 204 signifie une branche supplémentaire dans le code qui pourrait être évitée. Cela complique le code du client et, dans certains cas, le code du serveur (selon que vous utilisez des monades d’entité/modèle ou des entités/modèles simples; et que je fortement recommande de ne pas s'approcher des monades d’entité/modèle, cela peut conduire à de méchants bugs où, à cause de la monade, vous pensez qu'une opération a réussi et renvoyez 200 ou 204 alors que vous auriez dû retourner quelque chose d'autre).
• Le code client est plus facile à écrire et à comprendre si 2xx signifie que le serveur a fait ce que le client a demandé, et 4xx signifie que le serveur n’a pas fait ce que le client a demandé et que c’est sa faute. Ne pas donner au client l'enregistrement que le client demandé par id est la faute du client, car le client a demandé un identifiant qui n'existe pas.

Dernier point mais non le moindre: la cohérence

• GET /users/9
• PUT /users/9 et DELETE /users/9

PUT /users/9 et DELETE /users/9 doivent déjà renvoyer 204 en cas de réussite de la mise à jour ou de la suppression. Alors, que doivent-ils retourner au cas où l'utilisateur 9 n'existerait pas? Cela n’a aucun sens de présenter la même situation sous forme de codes d’état différents en fonction de la méthode HTTP utilisée.

En outre, ce n'est pas une raison normative, mais une raison culturelle: si 204 est utilisé pour GET /users/9, la prochaine chose qui va se passer dans le projet est que quelqu'un pense que renvoyer 204 est bon pour les méthodes n-aire. Et cela complique le code client, car au lieu de simplement rechercher 2xx, puis de décoder le corps, le client doit maintenant rechercher spécifiquement 204 et, dans ce cas, ignorer le décodage du corps. Bud, que fait le client à la place? Créer un tableau vide? Pourquoi ne pas avoir cela sur le fil, alors? Si le client crée le tableau vide, 204 est une forme de compression stupide. Si le client utilise null à la place, une boîte de vers différente est ouverte.

Answer 10

204 est plus approprié. Surtout lorsque vous disposez d'un système d'alerte garantissant la sécurité de votre site Web, 404 dans ce cas serait source de confusion, car vous ne savez pas que certaines alertes 404 sont des erreurs de backend ou des demandes normales, mais que la réponse est vide.

Answer 11

Selon la RFC7231 - page59 ( https://tools.ietf.org/html/rfc7231#page-59 ), la définition de la réponse du code d'état 404 est la suivante:

6.5.4. 404 Introuvable Le code d'état 404 (Introuvable) indique que le serveur d'origine n'a pas trouvé de représentation actuelle de la ressource cible ou ne veut pas en révéler l'existence. Un code d'état 404 n'indique pas Si cette absence de représentation est temporaire ou permanente, le code de statut 410 (Gone) est préférable à 404 si le serveur Origin sait, probablement par un moyen configurable, que la condition est susceptible d'être permanente. Une réponse 404 est mise en cache par défaut; autrement dit, sauf indication contraire dans la définition de méthode ou les commandes de cache explicites (voir la section 4.2.2 de la [RFC7234]).

Et la principale chose qui soulève des doutes est la définition de ressource dans le contexte ci-dessus. Selon le même RFC (7231), la définition de ressource est la suivante:

Ressources: la cible d'une requête HTTP s'appelle une "ressource". HTTP ne limite pas la nature d'une ressource; il définit simplement une interface pouvant être utilisée pour interagir avec des ressources. Chaque ressource est identifiée par une ressource uniforme. Identificateur (URI), décrit dans la section 2.7 de la [RFC7230] Lorsqu'un client construit un message de requête HTTP/1.1, il envoie l'URI cible sous l'une des différentes formes, comme défini dans la (Section 5.3 de la [RFC7230]). une demande est reçue, le serveur reconstruit une adresse URI de demande effective pour la ressource cible (paragraphe 5.5 de la [RFC7230]). méthode de requête (section 4) et quelques champs d'en-tête modifiant la requête (section 5): en cas de conflit entre la sémantique de la méthode et toute sémantique impliquée par l'URI lui-même, comme décrit dans la Section 4.2.1, la sémantique de la méthode a priorité .

Donc, à mon avis, le code d'état 404 ne devrait pas être utilisé avec une requête GET réussie avec un résultat vide. (Exemple: une liste sans résultat pour un filtre spécifique)

Answer 12

Je dirais que ni l'un ni l'autre n'est vraiment approprié…. Comme on l'a dit - par exemple. Par @anneb, je pense moi aussi qu’une partie des problèmes découle de l’utilisation d’un code de réponse HTTP pour transporter un statut relatif à un service RESTful. Tout ce que le service REST a à dire sur son propre traitement doit être acheminé au moyen de codes spécifiques REST.

1

Je dirais que, si le serveur HTTP trouve un service prêt à répondre à une demande d'envoi, il ne devrait pas répondre avec un HTTP 404 - en fin de compte, le serveur a trouvé quelque chose - à moins que le serveur ne le lui ait explicitement indiqué. service qui traite la demande.

Supposons un instant l'URL suivante: http://example.com/service/return/test.

• Le cas A est que le serveur "recherche simplement le fichier sur le système de fichiers". S'il n'est pas présent, 404 est correct. La même chose est vraie, s'il demande à un type de service de fournir exactement ce fichier et que ce service lui indique qu'aucun nom de ce nom n'existe.
• Dans le cas B, le serveur ne fonctionne pas avec des fichiers «réels», mais la demande est en réalité traitée par un autre service - par exemple, une sorte de système de templates. Ici, le serveur ne peut faire aucune déclaration sur l’existence de la ressource car il n’en sait rien (à moins que le service qui le gère ne le lui ait dit).

Sans aucune réponse du service nécessitant explicitement un comportement différent, le serveur HTTP ne peut dire que 3 choses:

• 503 si le service censé gérer la demande n'est pas en cours d'exécution ou ne répond pas;
• 200 sinon le serveur HTTP peut effectivement satisfaire la demande - peu importe ce que le service dira plus tard;
• 400 ou 404 pour indiquer qu'il n'existe aucun service de ce type (par opposition à «existe mais est hors ligne») et que rien d'autre n'a été trouvé.

2

Pour en revenir à la question qui nous occupe: Je pense que l’approche la plus propre serait de ne pas utiliser de code de réponse HTTP autre que celui indiqué précédemment. Si le service est présent et répond, le code HTTP doit être 200 . La réponse doit contenir le statut que le service a renvoyé dans un en-tête séparé - dans ce cas, le service peut dire

• REST:EMPTY par exemple si on lui demandait de chercher qch. et cette recherche est revenue vide;
• REST:NOT FOUND si cela a été demandé spécifiquement pour qc. "Identique à l'identique" - soit un nom de fichier ou une ressource identifiée ou l'entrée n ° 24, etc. - et cette ressource spécifique n'a pas été trouvée (généralement, une ressource spécifique a été demandée et n'a pas été trouvée);
• REST:INVALID si une partie de la demande qui a été envoyée n'est pas reconnue par le service.

(notez que je les ai préfixés avec «REST:» afin de souligner le fait que ceux-ci peuvent avoir les mêmes valeurs ou le même libellé que les codes de réponse HTTP, mais ils sont complètement différents.)

3

Revenons à l'URL ci-dessus et examinons le cas B où service indique au serveur HTTP qu'il ne gère pas cette demande elle-même mais le transmet à SERVICE. HTTP ne sert que ce qui est restitué par SERVICE, il ne sait rien de la portion return/test car elle est manipulée par SERVICE. Si ce service est en cours d'exécution, HTTP doit renvoyer 200 car il a effectivement trouvé quelque chose pour gérer la demande.

Le statut retourné par SERVICE (et qui, comme indiqué ci-dessus, aimerait voir dans un en-tête séparé) dépend de l'action réellement attendue:

• si return/test demande une ressource spécifique: si elle existe, retournez-la avec le statut REST:FOUND; si cette ressource n'existe pas, retournez REST:NOT FOUND; cela pourrait être étendu pour retourner REST:GONE si nous savons qu'il a déjà existé et ne reviendra pas, et REST:MOVED si nous savons qu'il est parti hollywood
• si return/test est considéré comme une opération de recherche ou de type filtre: si le jeu de résultats est vide, retourne un jeu vide du type demandé et un statut de REST:EMPTY; un ensemble de résultats dans le type demandé et un statut de REST:SUCCESS
• si return/test n'est pas une opération reconnue par SERVICE: renvoyez REST:ERROR si elle est complètement fausse (par exemple, une faute de frappe telle que retrun/test), ou REST:NOT IMPLEMENTED si elle est planifiée pour plus tard.

4

Cette distinction est beaucoup plus nette que de mélanger les deux choses différentes. Cela facilitera également le débogage et rendra le traitement légèrement plus complexe, voire pas du tout.

• Si un HTTP 404 est renvoyé, le serveur me dit: «Je ne sais pas de quoi vous parlez». Bien que la partie REST de ma requête puisse être parfaitement correcte, je cherche par'Mach dans tous les mauvais endroits.
• D'autre part, HTTP 200 et REST: ERR me dit que j'ai obtenu le service mais que je me suis trompé dans ma demande auprès du service.
• De HTTP 200 et REST: EMPTY, je sais que je n’ai rien fait de mal - bon serveur, le serveur a trouvé le service, bonne demande auprès du service - mais le résultat de la recherche est vide.

Résumé

Le problème et la discussion découlent du fait que les codes de réponse HTTP sont utilisés pour indiquer l’état d’un service dont les résultats sont servis par HTTP, ou pour indiquer qc. cela n'entre pas dans le champ du serveur HTTP lui-même . En raison de cet écart, il est impossible de répondre à la question et toutes les opinions sont sujettes à de nombreuses discussions.L'état d'une demande traitée par un service et non pas le serveur HTTP NE DEVRAIT TELLEMENT PAS (RFC 6919) être indiqué par un code de réponse HTTP. Le code HTTP SHOULD (RFC 2119) ne contient que les informations que le serveur HTTP peut donner à partir de sa propre portée: savoir si le service a été trouvé pour traiter la demande ou non.

Au lieu de cela, une méthode différente DEVRAIT être utilisée pour informer un consommateur de l'état de la demande adressée au service qui traite réellement la demande. Ma proposition est de le faire via un en-tête spécifique. Idéalement, le nom de l'en-tête et son contenu suivent tous deux une norme qui permet aux consommateurs de travailler facilement avec ces réponses.

Instead, a different way SHOULD be used to tell a consumer about the state of the request to the service that is actually processing the request. My proposal is to do so via a specific header. Ideally, both the name of the header and its contents follow a standard that makes it easy for consumers to work with theses responses.

Answer 13

Après avoir regardé en question, vous ne devriez pas utiliser 404 pourquoi?

Basé sur RFC 7231 le code d'état correct est 204

Dans les réponses ci-dessus, j'ai remarqué un petit malentendu:

1.- la ressource est: /users

2.- /users/8 n'est pas la ressource, il s'agit de: la ressource /users avec le paramètre de route 8, le consommateur ne peut peut-être pas la remarquer et ne connaît pas la différence, mais l'éditeur le sait et doit le savoir! pour les consommateurs. période.

alors:

Basé sur RFC: 404 est incorrect car les ressources /users ont été trouvées, mais la logique exécutée à l'aide du paramètre 8 n'a trouvé aucune content à renvoyer en réponse. La réponse correcte est donc: 204

Le point principal ici est: 404 pas même la ressource n'a été trouvée pour traiter la logique interne

204 est un: j'ai trouvé la ressource, la logique a été exécutée mais je n'ai trouvé aucune donnée en utilisant vos critères donnés dans le paramètre route, je ne peux donc rien vous retourner. Je suis désolé, vérifiez vos critères et appelez-moi à nouveau.

200: ok j'ai trouvé la ressource, la logique a été exécutée (même quand je ne suis pas obligé de retourner quoi que ce soit), prenez ceci et utilisez-le à votre guise.

205: (la meilleure option d'une réponse GET) J'ai trouvé la ressource, la logique a été exécutée, j'ai du contenu pour vous, utilisez-la bien, oh au fait si vous allez partager cela dans une vue, veuillez rafraîchir la vue pour l'afficher.

J'espère que ça aide.

Answer 14

Twitter utilise 404 avec un message d'erreur personnalisé du type "Aucune donnée trouvée".

Réf.: https://developer.Twitter.com/en/docs/basics/response-codes.html

Answer 15

Encodez le contenu de la réponse avec une énumération commune permettant au client de l’activer et définissez la logique en conséquence. Je ne suis pas sûr de savoir comment votre client distinguerait la différence entre une "donnée introuvable" 404 et une "ressource Web introuvable" 404? Vous ne voulez pas que quelqu'un accède à l'utilisateurZ/ 9 et laisse le client s'interroger comme si la demande était valide mais qu'aucune donnée n'a été renvoyée. 

Answer 16

Pourquoi ne pas utiliser 410? Cela suggère que la ressource demandée n'existe plus et que le client ne doit jamais faire de demande pour cette ressource, dans votre cas users/9.

Vous pouvez trouver plus de détails sur 410 ici: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html