Une bonne approche de la synchronisation des données

Envisagez le scénario suivant Une application web sert des ressources par le biais d'une API RESTful. Un certain nombre de clients d'utiliser cette API. L'objectif est de conserver les données sur les clients synchronisé avec l'application web (dans les deux directions).

La façon la plus simple pour ce faire est de demander à l'API si les ressources ont changé depuis le dernier client synchronisé avec l'API. Cela signifie que le client doit demander à l'API pour les ressources appropriées accompagné par timestamp (pour voir si les données doivent être à jour). Cela me semble être l'approche avec le moins de frais généraux en termes de consommation inutile de la bande passante.

Cependant, j'ai le sentiment que cette approche a quelques inconvénients en termes de conception et de responsabilités. Par exemple, les API ne devriez pas avoir à traiter avec vérifier si les ressources ne sont pas à jour. Il semble que la seule responsabilité de l'API doit être de servir les ressources lors de la demande sans avoir à traiter avec la mise à jour de l'aspect. En suivant cette seconde approche, le client doit demander beaucoup de données chaque fois qu'il veut mettre à jour ses données afin de les garder synchronisés avec l'application web. En d'autres termes, le client devrait vérifier si les données qu'il a obtenu à dos est plus récent que les données stockées localement. Si ce processus se produit à intervalles de quelques minutes, cela peut devenir un lourd fardeau pour le système.

Suis-je en voyant cela correctement ou est-il un moyen de la route que je suis dominant?

InformationsquelleAutor Bart Jacobs | 2012-08-01
  1. 20

    C'est un problème assez commun, et une bonne approche peut vous aider à les résoudre. HTTP (le protocole d'application généralement utilisé pour construire des services RESTful) prend en charge une variété de techniques qui peuvent être utilisés pour garder les clients API en synchronisation avec les données sur le côté serveur.

    Si le client reçoit un Last-Modified ou E-Tag en-tête HTTP de la réponse, il peut utiliser cette information pour faire conditionnelle OBTENIR appels dans l'avenir. Cela permet au serveur d'indiquer rapidement avec un 304 – Not Modified de réponse du client précédemment stocké à la représentation de la ressource est toujours valide et précise. Ainsi, le serveur (ou encore mieux, un intermédiaire de proxy ou un serveur de cache) pour être aussi efficace que possible dans la façon dont elle répond à des demandes du client, en réduisant potentiellement coûteux allers-retours à un magasin de données.

    Si la réponse contient un Last-Modified en-tête et le client souhaite bénéficier de l'optimisation de la performance disponibles, ils doivent inclure une If-Modified-Since directive dans l'un des prochains OBTENIR de l'appel à la même URI, en passant dans le même horodatage valeur reçue. Cela indique au serveur pour OBTENIR uniquement les informations de l'autorité de back-end de la source si elle sait qu'elle a changé depuis ce temps. Votre serveur devra être construit à l'appui de cette technique, bien sûr.

    Un principe similaire s'applique à E-Tag en-têtes. Un E-Tag est un simple code de hachage représentant un certain état de la ressource à un moment donné dans le temps. Si le changement dans les ressources en aucune manière, du fait de son E-Tag valeur. Si le client voit un E-Tag dans une réponse qu'il devrait passer dans la suite des demandes pour la même URI, permettant ainsi au serveur de déterminer rapidement si le client a un up-to-date de la représentation de la ressource.

    Enfin, vous devriez probablement regarder le le temps d'interrogation technique de réduire le nombre de répétés des demandes émises par les clients au serveur. En essence, l'astuce est de délivrer de très longues requêtes GET au serveur à surveiller les données du serveur de changements. Le GET ne sera pas de retour une réponse jusqu'à ce que les données ont changé ou le très long délai d'attente des incendies. Dans ce dernier cas, le client vient juste de ré-même à long terme demande à l'affût de changements de nouveau. Voir aussi rubriques comme La comète et les Web Sockets qui sont similaires.

    • Ce que ce mec dit (utilisation standard HTTP fonctionnalité), mais ne pas utiliser GET pour cela, utilisez HEAD, puisque vous n'avez pas de soins sur les données réelles, mais plutôt (comme je l'ai compris) vous vous souciez si les données sont valides. Si les données ne sont pas valides, puis d'effectuer une GET-demande en vue de récupérer les nouvelles données.
    • ^ Grand point. La TÊTE est nettement plus léger et approprié pour ce genre de chose.
    • J'ai une question: Si le client émet un findAll pour un certain type de documents (par ex. une Personne.findAll() ), et de supposer que certains dossiers sont de retour par la banque de données locale. Comment le client savoir si il y a d'autres Personnes sur le serveur? Ou, à l'inverse, comment le serveur de dire qui enregistre le client possède déjà?
    • La synchronisation est un sujet complexe, spécialement lorsqu'il y a plusieurs nœuds impliqués. Des conflits, des données Obsolètes, les données Supprimées sont certaines des questions ne sont pas directement traitées par les conventions REST.
    • Je pense que vous pouvez le faire en obtenir tous les de la clé primaire ou la totalité de hachage à partir de ces documents et de faire un hachage crc32.
    InformationsquelleAutor Brian Kelly