Est-ce faux de retourner 202 «Accepté» en réponse à HTTP GET?

J’ai un ensemble de ressources dont les représentations sont paresseusement créées. Le calcul pour construire ces représentations peut durer 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 demande GET reçue pour la ressource commence 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, quand il devient disponible n’est pas important.

En raison de la mémoire limitée et du volume de requêtes, ni NIO ni les longues interrogations ne sont une option ( c’est-à-dire que je ne peux pas garder assez de connexions ouvertes, ni même toutes les requêtes en mémoire). ont passé, je persiste les demandes excédentaires). De même, les limitations du client sont telles qu’elles ne peuvent pas gérer un rappel d’achèvement. Enfin, notez que je ne suis pas intéressé par la création d’une ressource “usine” que l’on POST, car les allers-retours supplémentaires signifient que la contrainte temps réel par morceaux est plus grande que ce que l’on souhaite (de plus, bénéficier de la mise en cache).

J’imagine qu’il y a une certaine controverse à propos du retour d’un code d’état 202 “Accepted” en réponse à une requête GET, vu que je ne l’ai jamais vu en pratique, et son utilisation la plus intuitive trouvé quelque chose qui le décourage spécifiquement. De plus, je ne préserve pas à la fois la sécurité et l’idempotence?

Alors, que pensent les gens de cette approche?

EDIT : Je devrais mentionner que c’est pour une soi-disant API Web Business – pas pour les navigateurs.

Si c’est pour une API bien définie et documentée, 202 sonne exactement ce qu’il se passe.

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

En outre, la RFC ne donne aucune indication que l’utilisation de la valeur 202 pour une requête GET est incorrecte, alors qu’elle établit des distinctions claires dans d’autres descriptions de code (par exemple, 200).

La demande a été acceptée pour traitement, mais le traitement n’a pas été terminé.

Nous avons fait cela pour une application récente, un client (application personnalisée, pas un navigateur) POST une requête et le serveur retournait 202 avec un URI au “job” en cours de publication – le client utiliserait cet URI pour rechercher le résultat – cela semble bien correspondre à ce qui se faisait.

La chose la plus importante ici est de documenter le fonctionnement de votre service / API, et quelle est la réponse de 202.

De ce que je peux rappeler – GET est censé retourner une ressource sans modifier le serveur. Peut-être l’activité sera-t-elle enregistrée ou ce que vous avez, mais la demande doit être réexécutable avec le même résultat.

POST d’autre part est une demande de modification de l’état de quelque chose sur le serveur. Insérez un enregistrement, supprimez un enregistrement, exécutez un travail, par exemple. 202 serait approprié pour un POST renvoyé mais qui n’est pas terminé, mais pas vraiment une requête GET.

C’est tout à fait puritaine et pas très pratiqué dans la nature, donc vous êtes probablement en sécurité en retournant 202. GET devrait retourner 200. POST peut retourner 200 s’il est terminé ou 202 si ce n’est pas fait.

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