J'ai 2 ressources utilisateur et album. Un utilisateur a une liste d'albums. Pour obtenir des albums, il existe 2 REST.
L'absence d'album est-elle vraiment considérée comme une erreur? En supposant que les albums sont renvoyés sous forme de tableau JSON, la réponse courante à une telle situation serait un HTTP 200 avec un tableau vide comme corps.
Retourner 404 signale que la ressource n'existe pas, en quelque sorte dire qu'elle n'est même pas possible pour demander la liste des albums pour cet utilisateur particulier. Mais en fait, il est possible de retourner avec succès la liste des albums, c'est juste que la liste est vide. Cela ne me semble pas du tout exceptionnel. Cela contraste complètement avec la récupération d'un album spécifique en utilisant un ID qui n'existe pas (en utilisant votre autre point de terminaison); dans une telle situation, un 404 est correct.
Alors qu'un 204 semble meilleur qu'un 404, car il indique au moins au client que le requrest a réussi mais n'a pas de contenu, son intention n'est pas vraiment d'être utilisée pour signaler une "absence réussie". Au contraire, cela signale que la ressource existe, mais pour une raison quelconque, le serveur a choisi de ne pas inclure la ressource dans le corps de la réponse - par exemple, le but de la demande aurait pu être de simplement renvoyer certains en-têtes au client.
Un 204 peut également être utilisé en réponse à une demande POST où une action a été effectuée par le serveur sans nécessairement créer de nouvelle ressource (ce qui aurait impliqué un 201 CREATED), ou où il est pour une autre raison non pertinente pour retourner une ressource.
Je pense qu'il est clair que vous avez besoin d'un
GET /user/xxx/albums
HTTP/1.1 200 OK
[]
Le serveur d'hébergement de site Web génère généralement une page Web "404 Not Found" lorsqu'un utilisateur tente de suivre un lien rompu ou mort.
Le serveur a répondu à la demande mais n'a pas besoin de renvoyer un corps d'entité.
Vous devez évidemment générer une erreur 204. Si vous utilisez le 404, l'utilisateur peut être dérangé. De plus, vous utilisez 404 lorsque l'album ciblé n'existe pas. Utiliser 404 pour 1 et 2 est en manque de logique.
Voici ce que le RFC2616 qui définit le protocole HTTP dit sur les codes d'état:
Le premier chiffre du code d'état définit la classe de réponse. Les deux derniers chiffres n'ont aucun rôle de catégorisation. Il y a 5 valeurs pour le premier chiffre:
- 1xx: Informational - Request received, continuing process - 2xx: Success - The action was successfully received, understood, and accepted - 3xx: Redirection - Further action must be taken in order to complete the request - 4xx: Client Error - The request contains bad syntax or cannot be fulfilled - 5xx: Server Error - The server failed to fulfill an apparently valid request
Dans votre cas, la demande a réussi, mais il n'y a aucun album à afficher, vous devez donc absolument utiliser un statut de la catégorie 2xx.
Voici ce que dit le RFC sur le statut 204:
10.2.5 204 Aucun contenu
Le serveur a répondu à la demande mais n'a pas besoin de renvoyer un corps d'entité et peut vouloir renvoyer une métainformation mise à jour. La réponse PEUT inclure une métainformation nouvelle ou mise à jour sous la forme d'en-têtes d'entité qui, s'ils sont présents, DEVRAIENT être associés à la variante demandée.
Si le client est un agent utilisateur, il NE DEVRAIT PAS changer sa vue de document de celle qui a provoqué l'envoi de la demande. Cette réponse est principalement destinée à permettre la saisie d'actions pouvant avoir lieu sans provoquer de modification de la vue active du document de l'agent utilisateur, bien que toute métainformation nouvelle ou mise à jour DEVRAIT être appliquée au document actuellement dans la vue active de l'agent utilisateur.
La réponse 204 NE DOIT PAS inclure de corps de message et est donc toujours terminée par la première ligne vide après les champs d'en-tête.
La RFC indique que le 204 est principalement destiné à autoriser les entrées, vous ne devez donc pas utiliser celui-ci. J'utiliserais le 200 dans ce cas.