Notre carte d'image permet aux utilisateurs de télécharger des images par des URL de colle-coller. Une application client envoie une demande postale à notre API avec une URL d'image indiquée dans le corps de la demande. Notre service Web reçoit la requête postale et le gère en téléchargeant l'image à partir de l'URL donnée à l'aide d'un client HTTP côté serveur ( Demande dans notre cas).
Dans un cas réussi, le service trouve l'image, le télécharge et le stocke sur le serveur. Le service renvoie HTTP 200 sur le client.
Maintenant, que si l'image ne peut pas être trouvée? Et si la tentative de téléchargement aboutit à http 404? Quel code d'erreur HTTP devrions-nous utiliser pour répondre au client?
HTTP 400 Bad Demande n'est pas applicable car la demande a été bien formée et tous les paramètres étaient valides.
HTTP 404 non trouvé n'est pas applicable car l'URL de la demande a été trouvée et servie bien que la L'URL de l'image n'était pas.
HTTP 502 Bad Gateway ne se sent pas juste parce qu'il n'y a rien de mal à notre serveur ou le serveur en amont (le serveur de l'image source). L'utilisateur vient de saisir une URL d'image qui n'existe pas.
Une expérience sur la question? Quel code d'erreur est le plus correct?
4 Réponses :
Étant donné que l'API détermine quelque chose qui n'est pas disponible, son service est également indisponible.
Le code d'état 503: Le service indisponible est le meilleur ajustement pour votre situation. Selon le Description RFC :
Le serveur est actuellement incapable de gérer la demande en raison d'une surcharge temporaire ou d'une maintenance du serveur. L'implication est qu'il s'agit d'une condition temporaire qui sera atténuée après un délai. Si elle est connue, la longueur du délai peut être indiquée dans une en-tête de nouvelle tentative. Si aucune nouvelle tentative est donnée, le client doit gérer la réponse comme pour une réponse de 500.
alternativement , si votre API prend en charge une façon de communiquer des erreurs (par exemple, de dire à l'utilisateur que les informations qu'il soumises sont incorrectes), vous pourrez peut-être utiliser cette méthode pour indiquer à l'utilisateur que l'utilisateur externe la ressource est indisponible. Cela pourrait être un peu plus convivial et peut éviter que certaines erreurs augmentent du côté de l'utilisateur.
Étant donné que l'application client envoie des demandes postales à votre serveur API, les codes de réponse doivent être générés en fonction du serveur reçu de votre cas, il s'agit de votre serveur API.
Si le serveur a reçu des informations correctes à partir de l'application client et du serveur détermine la demande comme valide, il doit renvoyer le code aproprié avec des messages d'erreur JSON ou basé sur l'en-tête correctement.
503 ne semble pas approprié. Ce n'est pas un cas du serveur omet de gérer la demande en raison de la surcharge ou de la maintenance. Le serveur fait gère la demande, il n'entraîne simplement pas la création d'une nouvelle ressource. En outre, la RFC déclare qu'il s'agit d'une condition temporaire qui "sera atténuée après un certain retard". Ce n'est pas un bon match pour ce que l'OP a décrit.
Tout d'abord, vous devez décider s'il s'agit d'une erreur client (4xx) ou d'une erreur de serveur (5xx). D'après ce que vous décrivez, cela ressemble plus à une erreur cliente. Le client a demandé la création d'une ressource d'une autre ressource (l'URL de l'image) qui n'existe pas.
Il n'y a pas de correspondance parfaite pour ce scénario, bien que l'on puisse faire un cas pour chacun des 2 codes de réponse suivants:
HTTP 409 Conflict : à partir du RFC :
La demande n'a pas pu être complétée en raison d'un conflit avec le courant
état de la ressource cible. Ce code est utilisé dans des situations où
L'utilisateur pourrait être capable de résoudre le conflit et de soumettre à nouveau le
Demande ...
Ceci s'applique à votre cas si vous envisagez la ressource cible dans un mauvais état (image non trouvée). Si quelqu'un fournit une image à l'URL spécifiée, cela transition efficacement votre ressource vers un état valide.
Ceci est également un bon match car, comme indiqué par la RFC, ce code implique que l'utilisateur peut être en mesure de résoudre le conflit (dans votre cas, l'utilisateur corrigerait cela en publiant l'image à l'URL spécifiée).
Les codes d'erreur HTTP ont été conçus en supposant que toutes les pages éventuellement servies étaient stockées localement, d'une manière ou d'une autre.
Votre scénario ne correspond pas à cette hypothèse et il ne devrait donc pas être surprenant que vous ne trouvez pas de codes qui correspondent correctement à votre facture.
Votre scénario "non trouvé" est en fait une erreur d'application et vous devez informer votre utilisateur de la situation en fournissant un message d'erreur sur le formulaire dans lequel il entra dans l'URL (ou renvoie une page d'erreur entièrement dédiée ou une autre). Ou choisissez néanmoins une erreur HTTP et acceptez la notion que ce sera une solution médiocre, peu importe quoi.
Maintenant, que si l'image ne peut pas être trouvée? Et si la tentative de téléchargement aboutit à http 404? Quel code d'erreur HTTP devrions-nous utiliser pour répondre au client?
La principale chose à garder à l'esprit: vous essayez de tromper le client à penser que vous êtes un site Web - Juste un magasin Dumb Document qui pourrait réagir à certains messages d'édition de contenu.
Pour le client, le principal moyen de communication est le corps de la réponse. Voir RFC 7231
Sauf lorsque vous répondez à une demande de tête, le serveur doit envoyer une représentation contenant une explication de la situation d'erreur et s'il s'agit d'une condition temporaire ou permanente.
Le code d'état est méta-data: visant à donner aux composants générique participant à l'échange une chance de savoir ce qui se passe (exemples: le navigateur Web n'a pas besoin de savoir quelle page Vous demandez de reconnaître un Redirection Réponse renvoyée par le serveur, Le navigateur Web demandant des informations d'identification lorsqu'il reçoit un 401 non autorisé réponse, caches Web Invalidation des entrées , ou non, en fonction du code d'état renvoyé par la réponse) .
HTTP 400 mauvaise demande n'est pas applicable car la demande a été bien formée et tous les paramètres étaient valides.
Oui, c'est exactement raison.
J'utiliserais probablement 500 Erreur de serveur interne , sur le motifs qu'il n'y a rien de mal avec le fichier _document que le serveur a reçu, les problèmes sont tous impliqués dans les effets secondaires de la mise en œuvre du serveur.
Une approche différente que vous puissiez considérer: 202 accepté . A grosement traduit "J'ai reçu votre message, j'ai compris votre message et je m'envoierai plus tard." Si vous n'avez pas besoin des effets secondaires pour être synchronisé, vous pouvez différer le jugement. Qui vous permet de faire des choses comme appliquer une stratégie de nouvelle tentative.
La représentation envoyée avec cette réponse doit décrire l'état actuel de la requête et le point sur (ou incorporer) un moniteur d'état pouvant fournir à l'utilisateur une estimation de la demande lorsque la demande sera remplie.
"Je vais y arriver plus tard; si tu veux savoir comment ça se passe, allez lui demander ->"
Parce que 202 est un code d'état de non-erreur, son effet sur la cache est différent de ceux d'un 4xx ou de 5xx. Si vous réfléchissez déjà à la mise en cache, vous voudrez les implications de cela à l'esprit.