Est-il erroné de renvoyer 202 "accepté" en réponse à HTTP GET?
J'ai un ensemble de ressources dont les représentations sont créées paresseusement. 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 demande GET reçue pour la ressource démarre le calcul sur le serveur. Si le calcul se termine dans 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 dans 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 considérable des demandes, ni les interrogations NIO ni les longues interrogations ne sont une option (ie. Je ne peux pas garder assez de connexions ouvertes, ni même je ne peux même pas mettre toutes les demandes en mémoire. " quelques secondes "se sont écoulées, 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, à la place. Enfin, notez que je ne suis pas intéressé par la création d’une ressource "usine" à laquelle on peut POST, car les allers-retours supplémentaires signifient que nous échouons plus que souhaité par la contrainte temps réel par morceaux (de plus, c’est une complexité supplémentaire; c'est aussi une ressource qui bénéficier de la mise en cache).
J'imagine qu'il y a une certaine controverse à renvoyer un code d'état 202 "Accepté" en réponse à une demande GET, vu que je ne l'ai jamais vu dans la pratique, et que son utilisation la plus intuitive est en réponse à des méthodes non sécurisées, mais je n'ai jamais trouvé quelque chose de particulièrement décourageant. De plus, ne préserve-t-on pas à la fois sécurité et idempotence?
Alors, que pensent les gens de cette approche?
EDIT: Je devrais mentionner que ceci concerne une API dite Web professionnelle - pas les navigateurs.
Si c'est pour une API bien définie et documentée, 202 sonne exactement comme il convient pour ce qui se passe.
Si c'était pour l'Internet public, je serais trop inquiet pour la compatibilité des clients. J'ai vu tellement de if (status == 200) codés en dur ... Dans ce cas, je renverrais un 200.
En outre, le RFC n'indique pas qu'utiliser 202 pour une demande GET est erroné, alors qu'il é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'est pas terminé.
Nous l'avons fait pour une application récente, un client (application personnalisée, pas un navigateur) a soumis une requête au serveur POST et le serveur renverrait 202 avec un URI pour le "travail" en cours de publication - le client utiliserait cet URI pour interroger le résultat - cela semble bien correspondre à ce qui était fait.
La chose la plus importante ici est quand même de documenter le fonctionnement de votre service/API et la signification de 202.
D'après mes souvenirs, GET est censé renvoyer une ressource sans modifier le serveur. Peut-être que l'activité sera consignée ou ce que vous avez, mais la demande devrait être réitérable avec le même résultat.
Le POST, par contre, 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 conviendrait pour un POST qui est retourné mais qui n'est pas terminé, mais pas vraiment une requête GET.
Tout est très puritain et mal pratiqué dans la nature. Vous êtes donc probablement en sécurité en renvoyant 202. GET devrait en renvoyer 200. POST peut renvoyer 200 si l'opération est terminée ou 202 si elle n'est pas terminée.
Dans le cas d'une ressource supposée avoir la représentation d'une entité clairement spécifiée par un identifiant (par opposition à une ressource "usine", comme décrit dans la question), je recommande de rester avec la méthode GET et Lorsque l’entité/la représentation n’est pas disponible en raison d’une création différée ou de toute autre situation temporaire, utilisez le code de réponse du service 503 indisponible qui est plus approprié et qui a été conçu pour des situations comme celle-ci.
Vous pouvez trouver des raisons à cela dans les RFC pour HTTP lui-même (veuillez vérifier la description du code de réponse 503), ainsi que dans de nombreuses autres ressources.
Veuillez comparer avec Code de statut HTTP pour les pages temporairement indisponibles . Bien que cette question concerne un cas d'utilisation différent, elle concerne en réalité exactement la même fonctionnalité de HTTP.