Meilleur code d'état HTTP API REST pour "Pas Encore Prêt, réessayez plus Tard"?

Question

Je suis le développement d'une API RESTful dans lequel http://server/thingyapi/thingyblob/1234 renvoie le fichier associé avec bidule #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 très certainement va ê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, thingy 1234 existe, mais le serveur n'a pas pour l'instant.

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 meilleur code de statut HTTP de retour dans un tel cas?

Answer 1

Je suggère 202 - Accepted. À partir de la documentation:

La demande a été acceptée pour le traitement, mais le traitement n'a pas été achevée. [...] Son but est de permettre à un serveur d'accepter une demande pour un autre processus (peut-être un lot orientée processus qui est exécuté qu'une fois par jour)

Answer 2

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 - le standard:

Le statut de la réponse codes commençant par le chiffre "5" indiquer les cas dans lesquels le serveur est conscient qu'il a commis une erreur ou est incapable de remplir la demande... le serveur DOIT inclure une entité [indiquant] si elle est temporaire ou permanente de la condition.

Note

• "a commis une erreur ou est incapable de remplir la demande": en dépit de leur titre de "Erreur de Serveur", ils ne sont pas seulement pour les erreurs de serveur.
• "temporaires ou permanentes": ces codes sont adaptés pour temporairement indisponible ressources, comme la vôtre.

Des codes disponibles, je dirais 503, "Service non disponible" était le mieux adapté:

Le serveur est actuellement incapable de répondre à la demande en raison d'une surcharge temporaire ou de la maintenance du serveur. L'implication est que c'est un état temporaire qui seront atténués après un certain délai. Si elle est connue, la durée de cette temporisation PEUT être indiqué dans un Retry-After-tête. Si pas de nouvelle tentative-Après est donné, le client DOIT gérer la réponse comme il le ferait pour une réponse 500.

Note:

• "une condition temporaire qui seront atténués après un peu de retard": true pour votre cas.
• temporaires "surcharge": pas de manière affectée vrai pour votre cas. Mais, il pourrait être soutenu, ont été votre serveur beaucoup plus rapide, le traitement par lots aurait déjà été fait lorsque le client en fait la demande, de sorte qu'il est une sorte de "surcharge": le client demande pour les ressources plus vite que le serveur peut les rendre disponibles.
• "le client DOIT gérer la réponse comme il le ferait pour une réponse 500.": qui est "Erreur Interne du Serveur", le genre de réponse que lorsque le serveur échoue à cause d'un bug. La norme semble être ce qui implique qu'un bien comportés client doit pas réessayer dans ce cas. Nouvelle tentative est adapté à votre service, pour que votre réponse doit inclure un Retry-After de la 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.

Définition de vos propres 5xx code d'état (591, par exemple), bien qu' autorisée, aurait la mauvaise sémantique:

Les codes d'état HTTP sont extensibles... les demandes DOIVENT comprendre la classe de code d'état, comme indiqué par le premier chiffre, et traiter les non reconnus réponse comme étant équivalent à la x00 code d'état de la classe

Les Clients de traiter votre propre code d'état, 500, "Erreur Interne du Serveur", qui, comme je l'ai expliqué ci-dessus) ne serait pas juste.

Answer 3

Une autre option: 503 - Service Unavailable.

Answer 4

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.

Answer 5

Quelques autres options:

• 204 - Pas De Contenu
• 206 - Partielle, Du Contenu
• 303 - Voir Les Autres
• 406 - Pas Acceptable
• 417 - Échec De L'Attente

Plus d'options/explications du W3C