Par exemple, il existe une API reposante GET http://luexu.com/users/{page} pour répertorier les utilisateurs de la Nième page. Supposons qu'il y ait 20 utilisateurs dans chaque page. Il y a 100 utilisateurs au total dans la base de données. GET http://luexu.com/users/5 renvoie le 80e au 100e utilisateurs.
Alors que diriez-vous de la requête GET http://luexu.com/users/10 code>? c'est sur le nombre total d'utilisateurs. Quelle est la meilleure conception pour renvoyer une liste vide, un tableau vide [] ou 404?
200?
{
"code": 404,
"msg": "Not Found",
"data": null
}
3 Réponses :
Renvoyer 404 ne conviendra pas aux cas où vous avez une page partielle (par exemple, vous avez 85 utilisateurs), donc j'irais avec une liste vide, 404 suites mieux lorsque vous avez une question binaire, ressource trouvée ou non. p>
Je voudrais jeter un œil à la question similaire suivante: Le service de repos renvoie 404
c'est logique.
Et le code 204?
En HTTP, 204 No Content signifie quelque chose de très spécifique - que le corps du message a une longueur de zéro octet.
Le code d'état 204 (Aucun contenu) indique que le serveur a satisfait à la demande et qu'il n'y a aucun contenu supplémentaire à envoyer dans le corps de la charge utile de la réponse.
Vous ne devriez donc pas y penser si vous envoyez, par exemple, un document encodé en json.
Si une liste vide est une représentation acceptable de la ressource, alors utiliser 200 comme code de réponse est très bien. Par exemple, considérez cet URI pour le débordement de pile lui-même.
Depuis le 01/06/2019, il y a beaucoup moins de 999 pages de questions avec ces balises, mais le serveur n'a aucun problème à calculer la représentation correcte de cette page (y compris les informations selon lesquelles la page numérotée la plus élevée est 426). Par conséquent, la sémantique de 200 convient parfaitement.
404 signifie qu'aucune représentation de la ressource n'était disponible. Tous les codes de réponse de classe 4xx indiquent une erreur avec la requête - dans ce cas, cela suggère que le client a fait une erreur avec l'URI. Cela pourrait être une condition temporaire (vous ne devriez pas poser de questions sur cette ressource pour le moment). Cela pourrait aussi être bien, si ce que vous voulez indiquer, c'est que le client a quitté le chemin heureux du protocole de domaine.
Comment choisir? Je pars de cette observation dans la spécification HTTP
le serveur DEVRAIT envoyer une représentation contenant une explication de la situation d'erreur, et s'il s'agit d'une condition temporaire ou permanente.
Alors, qu'est-ce qui est utile au client? Une représentation du problème, ou une représentation d'une collection vide? Cela peut être une question difficile lorsque les mêmes ressources sont utilisées pour différentes choses.
C'est l'une de ces questions qui n'a pas de "meilleure" réponse.
Tout ce que vous pouvez faire est de regarder les options et de choisir ce qui fonctionne le mieux pour votre scénario.
En règle générale, j'évite personnellement de renvoyer 404. La raison est que l'on ne sait pas pourquoi vous avez obtenu un 404. Vous pourriez obtenir un 404 parce que votre URL est erronée, donc si vous faites un choix de conception pour renvoyer 404 lorsque il n'y a pas de données alors vous vous retrouvez dans une situation peu claire. Comment savez-vous pourquoi vous avez 404? Ce n'est pas bon.
Renvoyer un 200 avec un tableau vide est parfaitement bien. Renvoyer 204 parfaitement bien aussi.
L'important est de faire un choix, d'être cohérent et de documenter le choix afin que les utilisateurs de votre API sachent que vous avez fait ce choix et pourquoi.
Cohérence et clarté, visez cela.
Comment les clients utiliseront-ils les données - les informations selon lesquelles il n'y a aucun utilisateur sont-elles utiles au client?
zéro utilisateur est inutile pour le client.
Un bon article sur ce sujet: medium.com/@santhoshkumarkrishna/...