Est-il incorrect de renvoyer 202 "Accepté" en réponse à HTTP GET?

Question

J'ai un ensemble de ressources dont les représentations sont créées de manière paresseuse. Le calcul pour construire ces représentations peut prendre de quelques millisecondes à quelques heures, en fonction de la charge du serveur, de la ressource spécifique et de la phase de la lune.

La première requête GET reçue pour la ressource démarre le calcul sur le serveur. Si le calcul se termine en quelques secondes, la représentation calculée est renvoyée. Sinon, un code d'état 202 "Accepté" est renvoyé et le client doit interroger la ressource jusqu'à ce que la représentation finale soit disponible.

La raison de ce comportement est la suivante : si un résultat est disponible en quelques secondes, il doit être récupéré dès que possible ; sinon, le moment où il devient disponible n'est pas important.

En raison de la mémoire limitée et du volume énorme de requêtes, ni NIO ni le long polling ne sont une option (c'est-à-dire je ne peux pas garder suffisamment de connexions ouvertes, ni même stocker toutes les requêtes en mémoire ; une fois que "quelques secondes" se sont écoulées, je persisterai les demandes en excès). De même, les limitations du client font qu'ils ne peuvent pas gérer un rappel de fin, à la place. Enfin, notez que je ne suis pas intéressé par la création d'une ressource "usine" à laquelle on envoie un POST, car les allers-retours supplémentaires signifient que nous ne respectons pas la contrainte en temps réel morcelée plus que désiré (de plus, c'est une complexité supplémentaire ; de plus, c'est une ressource qui bénéficierait de la mise en cache).

J'imagine qu'il y a une certaine controverse sur le fait de renvoyer un code d'état 202 "Accepté" en réponse à une demande GET, étant donné que je ne l'ai jamais vu en pratique, et son utilisation la plus intuitive est en réponse à des méthodes non sécurisées, mais je n'ai jamais trouvé quoi que ce soit décourageant spécifiquement. De plus, est-ce que je ne préserve pas à la fois la sûreté et l'idempotence?

Alors, que pensent les gens de cette approche?

MODIFIER : Je devrais mentionner que ceci est pour une prétendue API web d'entreprise - pas pour les navigateurs.

Answer 1

Si c'est pour une API bien définie et documentée, 202 semble tout à fait approprié pour ce qui se passe.

Si c'est pour l'Internet public, je serais trop préoccupé par la compatibilité des clients. J'ai vu tellement de if (status == 200) codés en dur... Dans ce cas, je retournerais un 200.

De plus, le RFC ne mentionne pas que l'utilisation de 202 pour une requête GET est incorrecte, alors qu'il fait des distinctions claires dans d'autres descriptions de code (par ex. 200).

La requête a été acceptée pour traitement, mais le traitement n'a pas été complet.

Answer 2

Nous avons fait cela pour une application récente, un client (application personnalisée, pas un navigateur) a envoyé une requête en POST et le serveur renverrait 202 avec une URI vers le "job" posté - le client utiliserait cette URI pour interroger le résultat - cela semble bien s'insérer dans ce qui était fait.

La chose la plus importante ici est de documenter comment fonctionne votre service/API, et ce que signifie une réponse de 202.

Answer 3

De ce que je me souviens - GET est censé renvoyer une ressource sans modifier le serveur. Peut-être que l'activité sera enregistrée ou quelque chose du genre, mais la requête devrait être exécutable de nouveau avec le même résultat.

POST, d'autre part, est une requête pour changer l'état de quelque chose sur le serveur. Insérer un enregistrement, supprimer un enregistrement, exécuter un travail, quelque chose comme ça. 202 serait approprié pour un POST qui a renvoyé mais n'est pas terminé, mais pas vraiment une demande GET.

C'est très puritain et peu pratiqué dans la nature, donc vous êtes probablement en sécurité en renvoyant 202. GET devrait renvoyer 200. POST peut renvoyer 200 s'il est terminé ou 202 s'il n'est pas terminé.

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

Answer 4

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

La raison pour cela peut être trouvée dans les RFC pour HTTP lui-même (veuillez vérifier la description du code de réponse 503), ainsi que sur de nombreuses autres ressources.

Veuillez comparer avec le code de statut HTTP pour les pages temporairement indisponibles. Bien que cette question concerne un cas d'utilisation différent, elle est en fait en lien avec la même fonctionnalité de HTTP.