J'ai une API REST traitant des factures. Désormais, chaque facture a une «liste de frais» spéciale après avoir été financée. Bien que tous ne soient pas destinés à être financés. J'ai un point final qui fournit des informations sur cette liste de frais pour chaque facture. Donc, si une facture a été financée, elle renvoie 200, si la facture n'a pas encore été financée (donc la ressource n'est pas encore disponible mais le sera) Je retourne 202 mais que se passe-t-il si la facture n'est pas destinée à être financée (la ressource n'est pas disponible et jamais sera, dans ce cas)?
J'ai pensé à utiliser:
2xx - n'a trouvé aucun code correspondant à la situation
3xx - en désaccord avec "le client doit prendre des mesures supplémentaires pour terminer la demande"
4xx - en désaccord avec les "situations dans lesquelles l'erreur semble avoir été causée par le client"
5xx - en désaccord avec "le serveur n'a pas réussi à répondre à une demande"
Des idées? Merci!
3 Réponses :
Tout d'abord, il est important de souligner que les codes d'état sont signifiés pour indiquer le résultat de la tentative du serveur de comprendre et de satisfaire la demande du client.
Donc, si la ressource n'est pas disponible signifie qu'une telle ressource n'existe pas (donc aucune représentation ne peut être trouvée pour une telle ressource), alors 404 est un choix tout à fait raisonnable:
Le code d'état
404(Not Found) indique que le serveur d'origine n'a pas trouvé de représentation actuelle pour la ressource cible ou n'est pas disposé à en révéler une.
D'après votre question, je peux comprendre que pas destiné à être financé ne signifie pas qu'une représentation n'existe pas pour une telle ressource. Donc, si la ressource existe (et qu'il y a une représentation pour elle), alors un < code> 200 semble très bien:
Le code d'état
200(OK) indique que la requête a réussi.
J'ai également pensé à 404 comme la première option, mais sa description comme «erreur causée par le client» ne correspond pas tout à fait. Ce n'est pas la "faute" du client qui ne sera pas financée, c'est juste un type de facture
@ SimonaChovancová J'ai ajouté plus de détails à ma réponse. En résumé, d'après ce que je peux comprendre, pas destiné à être financé ne signifie pas qu'une représentation n'existe pas pour une telle ressource. Dans ce cas, 200 est très bien.
Hm, pas destiné à être financé signifie que la ressource (liste des frais) n'existe pas et n'existera jamais.
J'ai un point de terminaison qui fournit des informations sur cette liste de frais pour chaque facture. Donc, si une facture a été financée, elle renvoie 200, si la facture n'a pas encore été financée (donc la ressource n'est pas encore disponible mais le sera) Je retourne 202 mais que se passe-t-il si la facture n'est pas destinée à être financée (la ressource n'est pas disponible et jamais sera, dans ce cas)?
Une chose importante à comprendre dans REST, c'est que les métadonnées (codes d'état, en-têtes) décrivent des ressources (documents), pas des entités de domaine.
Parfois, cette idée est exprimée "votre modèle de ressource n'est pas votre modèle de domaine".
Le client spécifique à votre domaine est censé examiner les charges utiles des réponses; les métadonnées décrivent les préoccupations indépendantes du domaine de la ressource hypermédia elle-même, afin que les composants génériques (navigateurs, caches, proxies, araignées) puissent y contribuer.
Une autre façon d'exprimer la même idée: ce que nous faisons vraiment, c'est d'envoyer des messages dans les deux sens. Le message pour le client spécifique au domaine appartient à la charge utile; c'est donc là que vous communiqueriez au client ce qui se passe avec la facture. Les métadonnées sont utilisées pour décrire des choses comme "combien de temps ce message particulier doit-il être mis en cache?"
Si je concevais votre API, la plupart des réponses utiliseraient 200 OK comme code d'état; avec le 404 Not Found occasionnel lorsqu'il apparaît qu'il peut y avoir une faute d'orthographe dans l'URI cible.
(Je n'utiliserais probablement pas 202 Accepté comme vous Je l'ai décrit, car la sémantique a une signification différente - 202 est beaucoup plus proche de "J'ai compris votre demande, mais il va me falloir un certain temps pour préparer le document")
Je suis d'accord. Chaque cas, les listes OP sont des cas commerciaux et donc 200 est approprié à moins que quelque chose ne se passe "mal" au niveau des ressources.
Je partage votre point de vue général, mais j'ai le sentiment que la question dans ce cas est légèrement différente. D'après ce que j'ai compris, le PO ne demande pas le statut d'une ressource et devient ensuite «non financé», mais demande une ressource (la liste des frais) associée à une autre ressource (la facture), qui n'est pas encore disponible ou ne sera jamais être. Par exemple. / facture / 123 / frais pourrait renvoyer soit 202 (revenir plus tard) ou 404 (introuvable, ce qui signifie qu'il ne sera jamais disponible).
Selon https://tools.ietf.org/html/rfc7231 # section-6.5.4 :
Le code d'état 404 (non trouvé) indique que le serveur d'origine a ne trouve pas de représentation actuelle pour la ressource cible ou n'est pas prêt à révéler qu'il en existe un. Un code d'état 404 ne indiquer si ce manque de représentation est temporaire ou permanent; le code d'état 410 (Gone) est préférable à 404 si le le serveur d'origine sait [...] que la condition est susceptible d'être permanente.
Et aussi:
Le code de statut 410 (Gone) indique que l'accès à la ressource cible n'est plus disponible sur le serveur d'origine et que cette condition est susceptible d'être permanente.
Donc, si vous avez une ressource qui ressemble à / facture / 123 / feelist et que cette ressource ne sera jamais disponible, alors la plus proche que vous pouvez obtenir est 410 car 404 n'a aucune indication quant à savoir si la condition est permanente ou non.