Comment puis-je choisir un code d'état HTTP API REST pour “Pas Encore Prêt, réessayez plus Tard”?
Je suis le développement d'une API RESTful dans lequel http://server/thingyapi/thingyblob/1234
renvoie le fichier (aka "blob") associée truc #1234 à télécharger. Mais il se peut que la demande est faite à un moment où le fichier n'existe pas sur le serveur mais plus certainement sera être disponible à une date ultérieure. Il y a un processus de traitement par lots dans le serveur qui génère toutes les gouttes pour tous les bidules. Truc 1234 existe déjà et ses données, autres que le blob, est déjà disponible. Le serveur n'a pas obtenu de générer des truc 1234 du blob encore.
Je ne veux pas rentrer 404; c'est pour les machines qui n'existent pas. C'est un truc qui existe, mais son blob n'a pas été généré encore. Un peu comme une vidéo YouTube qui est "en cours de traitement." Je ne pense pas que la redirection de codes serait bon que ce soit; il n'y a pas "d'autres" URL de l'essayer.
Quel est le bon code d'état HTTP de retour dans un tel cas?
- en quelque sorte liée
- Tout d'abord, si thingy 1234 n'a pas encore de GET-pouvoir de représentation, en quel sens est-il exister en tant que ressource (du point de vue du client)? Le fait que, à l'intérieur de du serveur il y a une file d'attente de travail pour créer 1234, ne semble pas impliquer que les ressources 1234 existe. Deuxièmement, d'où vient le client d'obtenir l'URI .../thingyblob/1234? Le serveur ne devrait probablement pas avoir fourni d'URI pour le client jusqu'à ce que la ressource a été réellement OBTENIR-mesure.
- Un truc a d'autres propriétés qui ne méritent pas d'autres que le blob. Ce n'est que la goutte qui prend du temps à générer. Client obtient ceux, par exemple, serveur/thingyapi/bidule/1234
- double possible de Est-ce mal de retour 202 "Accepté" en réponse à HTTP GET?
- Le HTTP norme fournit des directives sur lequel les codes de statut pour lesquelles les situations. Cette question n'est donc pas vraiment principalement opinion.
- Que diriez -
204
"Aucun Contenu"? Indique que le serveur a traité avec succès la demande et n'est pas le retour de tout contenu [à cette époque].
Vous devez vous connecter pour publier un commentaire.
Je suggère
202 - Accepted
. À partir de la la documentation:Le "problème", tel qu'il est, est sur le côté serveur: le client a fait un bien formé, mais le serveur ne peut pas la satisfaire. Je suis donc enclin à une "Erreur de Serveur", 5xx code d'état.
Dit - RFC 7231 (l'actuel HTTP standard, italiques ajoutés):
Note
Des codes disponibles, je dirais 503, "Service Non Disponible" était le mieux adapté:
Remarque:
Retry-After
valeur. Vous pouvez fournir la valeur de l'estimation des temps de réalisation de la prochaine exécution du traitement par lots, ou de l'exécution de l'intervalle du processus de traitement par lots.De la définition de votre propre 5xx code d'état (591, par exemple), bien que permis, aurait la mauvaise sémantique:
Clients de traiter votre propre code d'état comme 500, "Erreur Interne Du Serveur", qui ne serait pas juste.
307 - TEMPORARY REDIRECT
qui est bon, si vous voulez forcer le côté client d'attendre ailleurs pendant que votre ressource est "prêt"Je pense que 423 - Verrouillé peuvent être utilisés à cette fin:
Une autre option:
503 - Service Unavailable
.L'URL ne correspond pas à une demande d'un truc.
http://server/thingyapi/thingyblob/1234
Le client demande un thingyblob, qui n'existe pas. Si elle existait, vous donner à eux.
404.
503
est une réponse appropriée. De ne pas mentionner certains autres étranges suggestions.Depuis votre ressource n'est pas prêt, vous le savez sans doute, quand (à peu près), il sera disponible et lorsque le client peut retenter sa demande. Cela signifie que vous pourriez vouloir utiliser Retry-After-tête. Cet en-tête est valide avec 503 (Service Indisponible), ce qui signifie que tout le site est en maintenance, et 3xx (Redirection) des réponses.
À mon avis 302 (Trouvé) avec Retry-After-tête serait la meilleure option, mais je ne suis pas sûr de l'Emplacement du champ d'en-tête de réponse peut être égal à l'url de la requête. C'est la circulaire de redirection, de toute façon.
501 - Pas Mis En Œuvre
Exactement comme la façon dont il sonne. Une fonctionnalité qui n'est pas encore mis en œuvre, mais implique une disponibilité future.
Voici un lien vers un résumé de 5xx erreurs.
409 Conflit
Indique que la demande n'a pu être exécutée en raison du conflit dans la demande, comme un conflit de validation dans le cas de plusieurs mises à jour. [Source Wikipedia.]
Cela pourrait être approprié.
Si vous ne pouvez pas répondre à la demande en renvoyant les données - alors ce n'est pas un succès. Je pense 202 suggère que le serveur a mis en file d'attente de la demande et il va répondre à la demande plus tard. Mais dans votre cas, la demande est pour les données maintenant et a échoué. Si vous réessayer plus tard, c'est une autre demande.
Je pense que vous avez un conflit.. vous voulez que les données.. mais ses cours de modification /mise à jour. Ce serait également le cas si Thingy1234 existait déjà et a été téléchargé avec succès avant, mais maintenant, était en cours de modification a été n'était pas disponible alors que le montage a été prendre place.