Qu'est-ce qu'un bon code d'état de réponse à POST lorsque la ressource parent n'est pas trouvée?

J'ai le point de terminaison suivant:

a/{id}/b

et souhaitez créer une demande d' benvoi POST. Si aavec donné {id}n'est pas trouvé, dois-je répondre avec 404 NOT_FOUNDou peut-être avec 409 CONFLICT?

Il s'agit de gérer simplement a/{id}, l'astuce est qu'ici une sous-ressource est utilisée.

— Opale
source

Copie possible de Comment gérer les règles métier avec une API REST?

— moucher

Réponses:

404 NOT FOUNDsemble la réponse appropriée, car la ressource avec cet ID n'existe pas. C'est très clair à comprendre et vous attendez la même réponse si a/{id}est appelé.

409 CONFLICTne me semble pas le meilleur choix, car dans votre exemple, vous retournerez un 409 lorsque la ressource parent n'a pas été trouvée :).

Mais se souvient que la chose la plus importante est d'être cohérent dans votre API

— Dherik
source

Je suis d'accord. Si vous essayez d'écrire dans un dossier qui n'existait pas, s'agit-il d'un conflit ou d'une erreur de dossier manquante? Cela me semble plus intuitif de cette façon.

— Neil

Un "dossier" vous voulez dire un chemin qui n'existe pas?

— Dherik

Je veux dire un dossier, comme sur le système de fichiers.

— Neil

Pouvez-vous détailler le scénario? Parce que ça dépend. Si le dossier était prévu pour le serveur et (pour une raison quelconque) ne sont pas là, je pense que c'est une erreur de serveur (5xx) pas une erreur client (4xx). Si cette valeur de dossier a été passée par le client à la ressource (comme la id), est 404. Mais si le dossier a été passé dans le corps, cela pourrait être autre chose (412, 422 ... quelque chose à représenter "échec de validation: le dossier fait n'existe pas"). C'est une bonne question à poser et à discuter.

— Dherik

Si vous demandez au serveur un fichier avec le chemin /nonexistent/help.html et que le dossier / inexistant n'existe pas, il n'y a qu'une seule réponse claire à cela. Fichier 404 introuvable! Il pourrait même exister un /home/help.html, et la réponse ne serait pas différente. Il s'agit clairement d'une application REST, mais je ne vois aucune raison pour laquelle la logique changerait. Le parent doit d'abord exister.

— Neil

En plus de la réponse de @ Dherik.

Les URI sont des identifiants , nous devons donc garder à l'esprit que ( /a/{id}/best un identifiant). L' URI n'a pas de sens pour le WWW, tout comme pour le client HTTP.

404 est la bonne réponse . En substance, le serveur répond

Je n'ai trouvé aucune ressource avec un tel identifiant. Ressource introuvable ¹

Que la ressource manquante soit parent ou enfant n'a pas d'importance.

Nous, développeurs, voyons les hiérarchies et les chemins dans l'URI, mais pas les clients HTTP. En d'autres termes, HTTP est uniquement destiné à être interprété par les clients HTTP mais pas par les humains (développeurs, utilisateurs finaux, etc.).

En cas de doute, ne demandez pas quel code a du sens pour vous (humain). Demandez-vous quel code a du sens pour le client HTTP. Comment voulez-vous que le client HTTP se comporte?

Pourquoi? Parce qu'un code d'état oblige ces clients à effectuer certaines opérations. Par exemple, 302 . Ce code oblige généralement les navigateurs Web à rediriger vers un emplacement spécifique (URI) informé dans les en-têtes de réponse.

Ce n'est peut-être pas votre cas, mais il est important d'en être conscient. En fin de compte, les codes d'état HTTP sont adressés aux clients HTTP. Pas à nos applications. Pas aux personnes.

^{1: 409 est rarement implémenté comme erreur de navigation. Cela implique généralement l'exécution d'opérations à distance (suppression, mise à jour, nouvelle, etc.). Mais l'URI devrait exister. Sinon, 404 prévaudra}

— Laiv
source