Est-ce mal de retour 202 “Accepté” en réponse à HTTP GET?

J'ai un ensemble de ressources dont les représentations sont paresseusement créé. Le calcul de construire ces représentations peuvent prendre n'importe où de quelques millisecondes à quelques heures, en fonction de la charge du serveur, les ressources, et la phase de la lune.

La première demande reçue de la ressource commence le calcul sur le serveur. Si le calcul se termine dans quelques secondes, le calcul de la représentation est retourné. Sinon, une 202 statut "Accepté" le code est retourné, et le client doit interroger la ressource jusqu'à la représentation finale est disponible.

La raison de ce comportement est le suivant: Si un résultat est disponible dans un délai de quelques secondes, il doit être récupéré dès que possible; sinon, quand il devient disponible n'est pas important.

En raison de la limitation de la mémoire et le volume de demandes, ni NIO, ni le temps d'interrogation est une option (c'est à dire je ne peux pas garder près de suffisamment de connexions ouvertes, ni même je peut même s'adapter à toutes les demandes dans la mémoire, une fois que "quelques secondes" ont passé, je persiste, l'excès de demande). De même, le client limitations sont tels qu'ils ne peuvent pas gérer un rappel d'achèvement, à la place. Enfin, notez que je ne suis pas intéressé par la création d'une "usine" de ressources que l'un des Postes, que des allers-retours font que nous ne le par morceaux en temps réel contrainte de plus que ce qui est souhaité (d'ailleurs, c'est extra complexité; aussi, c'est une ressource qui serait à l'avantage de la mise en cache).

J'imagine que il ya une certaine controverse sur le retour d'un 202 statut "Accepté" code en réponse à une requête GET, vu que je n'ai jamais vu cela en pratique, et son utilisation est plus intuitive, en réponse à des méthodes dangereuses, mais je n'ai jamais trouvé quoi que ce soit de décourager. De plus, je ne suis pas à préserver à la fois la sécurité et l'idempotence?

Donc, ce que les gens pensent à propos de cette approche?

MODIFIER: je dois mentionner que c'est pour une entreprise web API--pas pour les navigateurs.

  • Personnellement, je pense que c'est une bonne idée, c'est exactement la définition d'un 202. Qu'il est rarement utilisé dans la pratique est à mon humble avis plus parce que quelques webdevelopers de soins sur le fonctionnement correct des codes de statut car ils sont plus utilisés pour navigateur / user-agent de l'interaction dans ce cas, un 202 donne aucun indice visible (leur donner un 200 et ils sont heureux...).
  • utilisez simplement 200. 202 est ce qu'il est censé être, mais dans la pratique, les gens ne vous attendez pas 202.
  • il a besoin d'un visa pour un 200 pour être utile dans la pratique cependant.
InformationsquelleAutor user359996 | 2010-11-04
  1. 60

    Si c'est pour un bien défini et documenté de l'API, 202 sons exactement droit pour ce qui se passe.

    Si c'est pour le public de l'Internet, je ne serais pas trop inquiet au sujet de la compatibilité client. J'ai vu beaucoup if (status == 200) codée en dur.... Dans ce cas, je voudrais revenir un 200.

    Aussi, le RFC ne donne aucune indication que l'utilisation de 202 pour une requête GET est mauvais, alors qu'il fait une distinction claire dans d'autres descriptions de code (par exemple, 200).

    La demande a été acceptée pour le traitement, mais le traitement n'a pas été achevée.

    InformationsquelleAutor Pekka 웃
  2. 11

    Nous l'avons fait pour une application récente, un client (application personnalisée, pas un navigateur) POST ed d'une requête et le serveur serait de retour 202 avec un URI pour le "travail" d'être publié - le client serait l'utilisation d'URI pour vérifier le résultat - ce qui semble parfaitement avec ce qui avait été fait.

    La chose la plus importante ici est de toute façon de documenter la façon dont votre service/API travaille, et qu'une réponse de 202 moyens.

    • +1 Merci pour votre commentaire. Bon point sur la documentation. Mais s'il vous plaît noter la clarification des modifications à ma question (voir "l'usine").
    • Eh bien, vous pouvez omettre cette URI, dans la réponse, si vous voulez juste pour interroger le même URI comme vous l'avez d'abord demandé. (Document simplement comment cela devrait fonctionner 🙂 )
    • Bonne idée, mais n'oubliez pas, je veux de la mise en cache, donc pas de POST. En outre, spécifie l'URI de la ressource, et non une méthode. Je vais prendre un Repos, plutôt que de RPC approche (désolé, un autre quelconque contrainte--mon mauvais).
    • Pour être précis, par de "repos", en fait, je veux dire "axée sur les ressources", ce qui est techniquement un peu plus que ce qui est spécifié par le RESTE les contraintes.
    InformationsquelleAutor nos
  3. 9

    De ce que je peux rappeler - GET est censé renvoyer à une ressource sans modifier le serveur. Peut-être que l'activité sera connecté ou qu'avez-vous, mais la demande doit être rerunnable avec le même résultat.

    POST sur l'autre main est une demande pour modifier l'état de quelque chose sur le serveur. Insérer un enregistrement supprimer un enregistrement, d'exécuter une tâche, quelque chose comme ça. 202 serait approprié pour un POST qui a retourné mais ce n'est pas fini, mais pas vraiment d'une requête GET.

    C'est très puritaine et pas bien pratiqué dans la nature, alors vous êtes probablement plus sûr, en retournant 202. OBTENEZ devrait rendement de 200. Le POST peut revenir 200 si il fini ou 202 si elle ne se fait pas.

    http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

    • Très bonne réflexion, mais je ne suis pas sûr qu'il s'applique ici: De ce que l'OP dit, cela semble être une bonne requête GET (en ce qu'elle ne change rien sur le serveur), il faut juste plus de temps à calculer et, dans ce cas, est à récupérer à un autre moment. Peut-être que les OP peuvent donner une interprétation commentaire. C'est une API de sorte qu'il est bien d'être "puritaine" pour l'amour d'une interface propre
    • Oh, la touche pekka. Vous avez raison, OBTENEZ est le chemin à parcourir. Et je ne pense pas que le HTTP spc vraiment pris en compte est qui ne sont pas prêtes. Donc, il pourrait aller de toute façon
    • (Maintenant, peu importe), autorité commentaire: Oui, je considère que c'est idempotent. Le ressource n'est ni modifié, ni créé, mais c'est plutôt représentation n'a pas encore été calculée.
    • Oh snap, nice lingo. Ya, je colle mon commentaire que vous êtes en territoire inconnu. Je dirais 202 fait le plus de sens, mais 200 est probablement plus sûr.
    • Oh, et c'est tout faux, car une requête GET ne devrait pas prendre autant de temps pour retourner le résultat souhaité (au moins, selon la spec).
    • Où faut-il dire cela? Aussi, si je retourne à 200, le client doit s'attendre à une représentation a été renvoyé, mais il n'a pas.
    • Je la renvoie. 202 ne pas correspondre à ce que GET ou POST, il me semble. Juste l'état d'esprit que j'étais quand j'ai regardé le protocole sur la chose me 202 n'existe que pour les requêtes GET. 202 devrait être bon pour vos besoins.

    InformationsquelleAutor Dlongnecker
  4. 0

    Dans le cas d'une ressource qui est censé avoir une représentation d'une entité qui est clairement défini par un IDENTIFIANT (par opposition à une "usine" de la ressource, comme décrit dans la question), je vous recommande de rester avec la méthode GET et, dans une situation où l'entité/représentation n'est pas disponible en raison de paresseux, de création ou de toute autre situation temporaire, utiliser le 503 Service non disponible code de réponse qui est plus approprié et a été effectivement conçu pour des situations comme celle-ci.

    Raisonnement pour ce qui peut être trouvé dans les Rfc pour HTTP lui-même (veuillez vérifier la description de la réponse 503 du code), ainsi que sur de nombreuses autres ressources.

    Veuillez comparer avec Le code d'état HTTP temporairement indisponible pages. Bien que cette question est sur un autre cas d'utilisation, il se rapporte en fait à la même fonction de HTTP.

    InformationsquelleAutor Hermes