Je dirais non plus.
Pourquoi pas 404 (non trouvé)?
Le code d'état 404 doit être réservé aux situations dans lesquelles une ressource n'est pas trouvée. Dans ce cas, votre ressource est une collection d'utilisateurs . Cette collection existe mais elle est actuellement vide. Personnellement, je serais très confus en tant qu'auteur d'un client pour votre application si j'en avais un 200
un jour et un 404
le lendemain simplement parce que quelqu'un avait supprimé quelques utilisateurs. Qu'est-ce que je suis supposé faire? Mon URL est-elle erronée? Quelqu'un a-t-il changé l'API et négligé de laisser une redirection.
Pourquoi pas 204 (sans contenu)?
Voici un extrait de la description du code d'état 204 par w3c
Le serveur a répondu à la demande mais n'a pas besoin de renvoyer un corps d'entité et peut souhaiter renvoyer des méta-informations mises à jour.
Bien que cela puisse sembler raisonnable dans ce cas, je pense que cela dérouterait également les clients. A 204
est censé indiquer qu'une opération a été exécutée avec succès et qu'aucune donnée ne doit être renvoyée. C'est parfait comme réponse à une DELETE
demande ou peut-être déclencher un script qui n'a pas besoin de renvoyer de données. Dans le cas de api/users
, vous vous attendez généralement à recevoir une représentation de votre collection d'utilisateurs. Envoyer un corps de réponse une fois et ne pas l'envoyer l'autre fois est incohérent et potentiellement trompeur.
Pourquoi j'utiliserais un 200 (OK)
Pour les raisons évoquées ci-dessus (cohérence), je retournerais une représentation d'une collection vide. Supposons que vous utilisez XML. Un corps de réponse normal pour une collection d'utilisateurs non vide pourrait ressembler à ceci:
<users>
<user>
<id>1</id>
<name>Tom</name>
</user>
<user>
<id>2</id>
<name>IMB</name>
</user>
</users>
et si la liste est vide, vous pouvez simplement répondre avec quelque chose comme ceci (tout en utilisant toujours a 200
):
<users/>
Dans tous les cas, un client reçoit un corps de réponse qui suit un certain format bien connu. Il n'y a pas de confusion inutile et de vérification du code d'état. De plus, aucune définition de code d'état n'est violée. Tout le monde est content.
Vous pouvez faire de même avec JSON ou HTML ou quel que soit le format que vous utilisez.