Notifications de progression du service HTTP / REST

Question

Je travaille sur une application Web qui soumet des tâches à un système maître / travailleur qui les répartit en sous-tâches dans une série d'instances de travail. Le maître de la file d'attente de travail s'exécute en tant que processus séparé (sur une machine distincte) et les tâches sont soumises au maître via des requêtes HTTP / REST. Une fois les tâches soumises à la file d'attente de travail, les applications clientes peuvent soumettre une autre requête HTTP pour obtenir des informations sur l'état des tâches.

Pour mon application Web, j'aimerais qu'elle fournisse une sorte de vue de barre de progression donnant à l'utilisateur une indication de l'état d'avancement du traitement des tâches. Le moyen évident de le mettre en œuvre serait un widget indicateur de progression AJAX qui interroge périodiquement la file d'attente de travail pour connaître l'état des tâches soumises. Ma question est la suivante: existe-t-il un meilleur moyen de réaliser cela sans procéder à des sondages fréquents?

J'ai envisagé de laisser l'application Web client ouvrir un socket de serveur sur lequel elle pourrait écouter les notifications du maître du travail. Une autre idée similaire que j'ai eu est d'utiliser XMPP ou un protocole similaire pour les notifications d'état. (Bien sûr, le système maître / opérateur doit être mis à jour pour fournir des notifications dans les deux cas, mais je possède le code qui permet de faire les mises à jour nécessaires moi-même.)

Avez-vous des idées sur la meilleure façon de configurer un système de notification comme celui-ci? Les efforts supplémentaires nécessaires en valent-ils la peine ou la solution de vote simple est-elle la solution?

Answer 1

Je suppose que cela dépend de quelques facteurs

• La précision du retour peut être précise (1 pour cent, 5 pour cent, 50 pour cent)
  Un retour d'information précis justifie la poursuite d'une sorte de barre de progression et de style de comète. Si vous ne pouvez que dire "Occupé ... attendez ... presque là ... terminé" alors un simple ajax "sommes-nous encore là" Le sondage est certainement plus facile à coder.
• Heure à laquelle le message Terminé doit être vu par le client
• Durée d'une tâche (1 seconde, 10 secondes, 10 minutes)
  
  1 seconde le rend un peu discutable. 10 secondes, ça vaut le coup. 10 minutes signifient que vous feriez mieux de suggérer à l'utilisateur de prendre une pause-café: -)
• Combien de demandes simultanées il y aura
  Sauf si vous avez un "spécial" serveur, les systèmes de style live push ont tendance à manger des connexions et vous serez maximisé assez rapidement. Le fait de devoir ajouter davantage de serveurs Web à une barre de progression sophistiquée pourrait nuire au budget.

J'ai un exemple de code sur 871184 qui montre une main roulée " frame pour toujours " qui semble bien fonctionner. Le projet pour lequel j’ai développé n’est pas si difficile, les opérations prennent quelques secondes et nous pouvons donner un pourcentage assez précis. Le code utilise asp.net et jquery, mais les techniques générales fonctionneront avec n’importe quel serveur et tout framework javascript.

modifier comme John souligne, les rapports d'état ne sont probablement pas le travail du service RESTful. Mais rien ne dit que vous ne pouvez pas ouvrir un iframe sur le client qui est relié à une page du serveur qui interroge le service. La théorie dit que le serveur et le service seront au moins plus proches l'un de l'autre: -)

Answer 2

Interrogation

Le client interroge régulièrement le serveur pour obtenir l'état de la réponse.

Avantages

• Etre vraiment RESTful signifie mettre en cache et mettre à l'échelle.

Inconvénients

• Ce n’est pas la meilleure réactivité si vous ne voulez pas trop interroger votre serveur.

Connexion permanente

Le serveur ne ferme pas sa connexion HTTP avec le client tant que la réponse n'est pas terminée. Le serveur peut envoyer un statut intermédiaire via cette connexion à l'aide de la procédure multipart HTTP.

Comet est le framework le plus connu pour implémenter ce comportement.

Avantages

• Meilleure réactivité, notifications presque en temps réel du serveur.

Inconvénients

• La limite de connexion est limitée sur un serveur Web. Garder une connexion ouverte trop longtemps risquerait, dans le meilleur des cas de charger votre serveur, d'ouvrir le serveur à des attaques par déni de service.

Client en tant que serveur

Faites en sorte que les mises à jour de l'état des publications sur le serveur et la réponse au client soient comme s'il s'agissait d'une autre application RESTful.

Avantages

• Le meilleur de tous les mondes, aucune ressource n'est gaspillée dans l'attente de la réponse, que ce soit du côté serveur ou du côté client.

Inconvénients

• Vous avez besoin d'un serveur HTTP complet et d'une pile d'applications Web sur le client
• Les pare-feu et les routeurs avec leur valeur par défaut "Aucune connexion entrante" va faire obstacle.

N'hésitez pas à modifier pour ajouter vos idées ou une nouvelle méthode!

Answer 3

Mon opinion est de rester fidèle à la solution de vote, mais cet article de Wikipedia sur HTTP vous intéresserait peut-être. Push technologies.

Answer 4

REST dépend de HTTP, qui est un protocole de requête / réponse. Je ne pense pas que vous obtiendrez un serveur HTTP pur rappelant le client avec le statut.

En outre, la création de rapports d’état n’est pas la tâche du service. Il appartient au client de décider quand ou si il souhaite que son statut soit signalé.

Answer 5

Recherchez Comet . Vous faites une demande unique au serveur et le serveur bloque et maintient la connexion ouverte jusqu'à ce qu'une mise à jour en statut ait lieu. Une fois que cela se produit, la réponse est envoyée et validée. Le navigateur reçoit cette réponse, la gère et demande immédiatement la même adresse URL. L'effet est celui d'événements poussés dans le navigateur. Il existe des avantages et des inconvénients et peut ne pas convenir à tous les cas d'utilisation, mais fournirait les mises à jour de statut les plus opportunes.

Answer 6

Vous pouvez également utiliser l'iframe à rafraîchissement automatique, mais les appels AJAX sont bien meilleurs. Je ne pense pas qu'il y ait d'autre moyen.

PS: Si vous ouvriez un socket à partir d'un client, cela ne changerait pas grand chose - le navigateur PHP afficherait la page comme étant toujours "en cours de chargement", ce qui n'est pas très convivial. (en supposant que vous poussiez ou vidiez le tampon pour afficher autre chose auparavant)