Utiliser le statut HTTP 202 pour les opérations asynchrones

Question

Je suis en train d'écrire une API REST pour un service qui va accepter de l'utilisateur fourni les données. Je tiens à garder toutes les opérations complètement asynchrone, cela comprend PUT, POST, DELETE et peut-être même OBTENIR des demandes. Mon idée est la réception de la demande, processus, il suffit de s'assurer qu'il est une demande valide et puis de passer un HTTP 202 réponse acceptée avec une url où les données seront éventuellement disponibles et un jeton de sorte que les requêtes suivantes peuvent être adaptées aux données traitées. Si la demande n'est pas valide alors je vais lui envoyer un HTTP 400.

Le client sera alors tenu de vérifier l'url que j'ai fourni à un certain moment dans l'avenir, et de transmettre le jeton. Si les données sont disponibles, j'retour normal de 200 ou 201 mais si je suis encore en train de traiter la demande, je vais envoyer un autre 202 indiquant le traitement n'est pas terminé. En cas d'erreur de traitement de données je vais envoyer 4xx ou 5xx d'état que nécessaire.

La raison pour laquelle je veux faire c'est le cas je peut vider toutes les demandes valides dans un pool de demande et d'avoir des employés retirer de la file d'attente et de traiter les demandes qu'ils sont disponibles. Car je ne sais pas la taille ou le nombre de travailleurs disponibles, je ne peux pas être certain que je peux obtenir à des demandes assez rapidement pour satisfaire les 30 seconde limite de Google App Engine.

Ma question est: suis-je en train de pervertir RESTE par le traitement des demandes de cette manière? Les navigateurs, par exemple, semble exiger une réponse immédiate aux demandes. Pour mes pages HTML j'ai l'intention de répondre avec de la structuration de la page, puis utiliser AJAX pour traiter les demandes de données.

Je suis surtout intéressé par des avis ou expérience dans le traitement des données en utilisant le RESTE de cette façon.

Answer 1

Je pense que votre solution est fine, l' Http status 202 est la réponse appropriée à utiliser dans ce cas précis, indiquant que la demande a été acceptée pour le traitement, mais le traitement n'a pas été achevée.

Ce que je voudrais changer un peu dans votre flux de travail sont l' Http status des demandes ultérieures.

Comme vous l'avez dit, l' 202 response doit retourner un Location header en spécifiant l'URL que le client doit utiliser pour surveiller l'état de sa précédente demande.
L'appel de cette Check-le-statut-de-mon-processus URL, au lieu de retourner un 202 dans le cas de processus en attente, je serais de retour:

1. 200 OK lorsque la demande est toujours en attente. La Réponse doit décrire l'état en attente du processus.
2. 201 Created lorsque le traitement est terminé. La Réponse en cas de GET/PUT/POST doit contenir l'Emplacement de la demande/création/mise à jour des ressources.

Answer 2

Ajouter mon grain de sel à une vieille question. Mon idée est similaire à systempuntoout et Avi Lin suggestions.

Je suis d'accord qu'un HTTP 202 réponse est approprié pour la demande initiale, avec une redirection vers une autre ressource via un Location - tête.

Je pense que l' Location URL devrait probablement inclure le jeton vous de référence pour se conformer à des attentes communes d'un Location redirection. Par exemple Location: /queue?token={unique_token} ou Location: /task/{unique_token}.

Je pense aussi que la ressource utilisée pour vérifier l'état du processus de retour d'un HTTP 200 réponse lors de l'action de "vérification de l'état" est réussi (pas un HTTP 202 parce que cela implique la demande actuelle a été "accepté").

Cependant, je pense que lorsque la nouvelle entité est créée "la vérification de l'état" doit retourner un HTTP 303 (Voir d'Autres) de la réponse avec un Location - tête de la nouvelle entité une fois qu'il a été créé. Ce qui est plus approprié que l'envoi d'un HTTP 201 car rien n'a été créé en raison de l' GET demande vient d'être effectué pour vérifier l'état.

Je pense aussi que la ressource utilisée pour vérifier l'état doit retourner les codes d'erreur de manière appropriée. Chaque fois que "la vérification de l'état" est effectuée avec succès, un code de réussite doit être retourné. Des erreurs peuvent être gérées au niveau de l'application (en cochant le corps de la réponse).

Answer 3

C'est une très vieille question, mais je tiens à offrir un point de vue légèrement différent de ce que je ne prétends pas être correct, juste mon point de vue.

Du point de vue du client

Commençons avec la première requête HTTP. D'abord et avant tout, la demande doit être POST. Vous envoyez un message au serveur pour créer une ressource. GET et PUT ne sont pas valables dans ce cas, parce que:

• Un GET n'est pas valide dans ce contexte, car une est destinée à obtenir la ressource à un endroit précis
• De vente n'est pas valable parce que vous n'êtes pas de la création de la demande, vous demandez au serveur pour créer la demande.

Du point de vue du service

Alors maintenant, vous êtes l'envoi d'un courrier au serveur pour traiter une demande. Le serveur a vraiment 3 valeurs de retour possibles (pas y compris le 4xx et 5xx erreurs):

• "201 Créé" indique que le service reçu la demande et a été en mesure de les traiter immédiatement ou dans un délai acceptable. Cette période de temps est complètement au service de la conception. C'est au développeur de service à la définir.
• "202 Accepté" indique que le service reçu la demande et de la traiter. Il est utilisé lorsque le service en sait quelque chose va prendre un certain temps. L'autre point de vue est que si le service est tributaire de toute autre opération asynchrone qu'il n'a aucun moyen de déterminer le résultat, alors il devrait retourner le "202 Accepté" réponse. Enfin, certains concepteurs peuvent tout simplement toujours revenir "202 Accepté", indépendamment de la façon dont rapidement, il peut être fait.
• Dans certains cas, vous obtiendrez un "302 Found". C'est généralement lorsque le service peut identifier une demande en générant une ressource qui existent déjà (et est toujours valide et pas dans un état d'erreur) et que la réutilisation d'une ressource existante est acceptable. Tous les services ne fonctionnent comme ceci: poster un commentaire sur l'un thread doit toujours créer de nouvelles ressources. Autres services: poste un ensemble de critères pour obtenir une liste des médecins qui produit le même liste des médecins. Si ces informations peuvent être réutilisées, puis la réutiliser.
• Avec toutes ces réponses, la "situation" en-Tête HTTP est retourné au client contenant où la ressource peut être trouvé. Ce qui est important et où certaines personnes ont tendance à diverger dans leur approche, comme vous le verrez plus tard. Si la ressource peut être réutilisée avec d'autres demandes, la "situation" devrait vraiment être générées de façon que la même demande toujours de générer la même Url. Cela fournit une bonne partie de la mise en cache et la réutilisation.

Lorsque le service a terminé la demande avec succès, il va créer de la ressource à l'emplacement qui a été renvoyée au client.

Maintenant c'est là que je commence à voir des choses un peu différente de la réponse ci-dessus.

Si le service ne parvient pas à remplir la demande, il convient toutefois de créer une ressource à l'emplacement qui a été retourné au client. Cette ressource doit indiquer la raison de l'échec. Beaucoup plus souple d'avoir une ressource de fournir des informations sur l'échec que d'essayer de chausse-pied dans le protocole HTTP.

Si le service reçoit la demande pour cette ressource avant qu'il soit terminé, il doit retourner un "404 not Found". La raison pour laquelle je pense qu'il devrait être un "404 not Found" c'est parce qu'il n'existe pas vraiment. Les spécifications HTTP ne dis pas que "404 not Found" ne peut être utilisé lorsqu'une ressource est jamais exister, qu'il n'existe pas de là maintenant. Ce type de réponse à un asynchrones flux d'interrogation est tout à fait correct à mon avis.

Il y a aussi le scénario de quand une ressource est censé être là pour un temps fixe. Par exemple, il peut s'agir de données basé sur une source qui est actualisé tous les soirs. Ce qui devrait arriver dans ces cas, c'est que la ressource doit être supprimé, mais un indicateur doit être fourni pour le service qu'il peut savoir de retour d'un "410 Gone" code d'état. Il s'agit essentiellement de dire au client que la ressource est là, mais n'est plus disponible (c'est à dire: peut-être expiré). L'action typique du client serait de soumettre à nouveau la demande.

Du point de vue du client à nouveau

Lorsque le client reçoit la réponse pour son POST initial, il devient le "Lieu" et en fait la demande au service à l'aide de l'URL à l'aide d'un GET (encore une fois, pas de POST). Le service sera généralement de réponse avec ces valeurs:

• "200 OK" indique que la demande ne soit terminée. Le résultat de la requête est renvoyée dans le contenu du corps, de fournir du contenu dans le format défini par l'Accepter en-tête HTTP.
• "404 not Found" serait de dire au client que la demande n'a pas encore complet, la ressource n'est pas encore là, et, dans ce cas, il devrait essayer de nouveau plus tard.
• "410 Gone" serait retourné dans les cas où le client peut tenter d'accéder à la ressource après une longue période de temps et il n'est plus là. Dans ce cas, il convient simplement de soumettre à nouveau la requête d'origine

La seule chose qui doit être souligné est que la ressource retournée est généralement dans un format qui peut définir le succès et l'échec des réponses. Le client doit être en mesure de déterminer à partir de cette ressource si il y a une erreur, ce qu'il était, et être en mesure de réagir en conséquence.

Aussi, le développeur de service peut faire en sorte que l'expiration du service et supprime l'erreur des ressources après une courte période de temps.

Donc, c'est ma pensée sur cette question. Il est très en retard à la fête, mais j'espère que les futurs lecteurs peuvent voir d'un point de vue légèrement différent d'un fréquemment posées question.