Quelle est la méthode RESTful de surveillance des modifications d’une ressource REST?

Question

S'il existe une ressource REST que je souhaite surveiller pour les modifications apportées par d'autres clients, quel est le meilleur moyen (et le plus RESTful) de le faire?

L’une des idées que j’ai eu à faire est de fournir des ressources spécifiques qui maintiendront la connexion ouverte au lieu de revenir immédiatement si la ressource n’existe pas (encore). Par exemple, étant donné la ressource:

/game/17/playerToMove

a " GET " sur cette ressource pourrait me dire que c'est au tour de mon adversaire de bouger. Plutôt que d'interroger continuellement cette ressource pour savoir quand c'est à mon tour de partir, je pourrais noter le numéro du mouvement (disons 5) et tenter de récupérer le prochain mouvement:

/game/17/move/5

Dans un "normal" Modèle REST, il semble qu'une requête GET pour cette URL renvoie une erreur 404 (non trouvée). Cependant, si au lieu de cela, le serveur maintenait la connexion ouverte jusqu'à ce que mon adversaire joue son coup, c'est-à-dire:

.

PUT /game/17/move/5

alors le serveur pourrait renvoyer le contenu que mon adversaire PUT dans cette ressource. Cela me fournirait à la fois les données dont j'ai besoin et une sorte de notification pour les cas où mon adversaire aurait déménagé sans avoir besoin de scrutation.

Ce type de régime est-il RESTful? Ou cela enfreint-il une sorte de principe REST?

Answer 1

La solution que vous proposez ressemble à longue interrogation , qui pourrait très bien fonctionner.

Vous demanderez / game / 17 / move / 5 et le serveur n'enverra aucune donnée jusqu'à la fin du déplacement 5. Si la connexion est interrompue ou si vous obtenez un délai d'attente, il vous suffit de vous reconnecter jusqu'à obtention d'une réponse valide.

L'avantage de ceci est que c'est très rapide - dès que le serveur aura de nouvelles données, le client les aura. Il résiste également aux connexions interrompues et fonctionne si le client est déconnecté pendant un certain temps (vous pouvez demander à / game / 17 / move / 5 une heure après son déplacement et obtenir les données instantanément, puis vous déplacer. sur move / 6 / et ainsi de suite)

Le problème avec le sondage long est chaque "sondage". lie un thread de serveur, ce qui casse rapidement des serveurs tels qu'Apache (car il est à court de threads de travail, il ne peut donc pas accepter d'autres requêtes). Vous avez besoin d'un serveur Web spécialisé pour répondre aux demandes d'interrogation longue. Le module Python tordu (un "moteur de réseau piloté par les événements") est idéal pour cela, mais cela demande plus de travail que la scrutation régulière.

En réponse à votre commentaire à propos de Jetty / Tomcat, je n'ai aucune expérience de Java, mais il semble qu'ils utilisent tous les deux un système similaire de pool de threads de travail pour Apache, ce qui posera le même problème. J'ai trouvé ce message qui semble résoudre exactement ce problème (pour Tomcat)

Answer 2

J'ai trouvé Cet article propose un nouvel en-tête HTTP, "When-Modified-After", qui fait essentiellement la même chose: le serveur attend et laisse la connexion ouverte jusqu'à ce que la ressource soit modifiée.

Je préfère une approche basée sur les versions plutôt que sur l’horodatage, car elle est moins exposée aux conditions de concurrence et vous donne un peu plus d’informations sur ce que vous récupérez. Des idées sur cette approche?

Answer 3

Je suggérerais un 404, si votre client visé est un navigateur Web, car le fait de garder la connexion ouverte peut bloquer activement les requêtes du navigateur du client dans le même domaine. C'est au client à quelle fréquence interroger.