1. Reformuler la question
Votre exemple suggère que les données sont en lecture seule du côté Drupal, avec une synchronisation unidirectionnelle uniquement. Je pense que c'est le facteur le plus important à considérer ici, car en fait, quelle que soit la solution que vous implémentez, ce sera une variante du stockage à distance, de la synchronisation et de la mise en cache locale - même si la mise en cache locale finit par être des entités dans la base de données Drupal.
Donc, la question, plutôt que d'être "stockage local vs stockage distant" va être:
- Si vous mettez en cache les données localement;
- Si vous mettez en cache les données en tant qu'entités réelles et utilisez des flux (ou similaires) pour synchroniser régulièrement les données; OU
- Si vous utilisez un module personnalisé qui fournit la synchronisation et la mise en cache.
Un article qui pourrait vous intéresser est " Entités distantes dans Drupal 7 ".
2. Mise en cache des données
En général, la mise en cache des données est une bonne idée:
Vous êtes protégé contre les pannes des autres services ou les dépassements de délai dans la connexion;
La présence de vos données dans votre base de données Drupal accélérera les opérations;
La présence de vos données dans votre base de données Drupal signifie que vous êtes plus susceptible d'obtenir une intégration avec d'autres modules, tels que des vues (bien que cela ne soit pas garanti).
Le seul avantage de ne pas mettre en cache les données est que vous n'obtenez jamais de données périmées, ce qui dans certains cas est préférable - il est parfois préférable de n'afficher aucune donnée plutôt que des données périmées. Je ne vois pas cela comme un avantage dans l'exemple que vous avez donné, je vais donc concentrer cette réponse sur une solution qui implique la mise en cache locale.
3. Entités locales + synchronisation
Si vous optez pour l'option d'avoir des entités locales et de les synchroniser vous-même, nous revenons à vos questions d'origine:
3.1 Nœuds vs entités personnalisées
La définition de ce qu'est exactement un nœud est assez ouverte. La page de documentation sur les nœuds suggère que les nœuds "publient" qui sont "stockés" sur votre site - aucun des deux ne s'applique à vos données;
En tant que développeur Drupal, je m'attendrais à ce que si quelque chose est un nœud, je devrais pouvoir le manipuler sur le site lui-même;
En tant qu'utilisateur Drupal, je m'attendrais également à ce que les nœuds puissent être modifiés;
Ce numéro de Drupal 8 https://drupal.org/node/2019031 suggère que le concept de "lecture seule" est celui qui s'appliquerait au niveau de l'entité, plutôt qu'au niveau du bundle. Si cela est mis en œuvre, vous en bénéficieriez en empruntant cette voie.
Pour résumer: vos données étant en lecture seule et stockées à distance, il est plus judicieux d'utiliser un type d'entité personnalisé pour représenter vos données.
3.2 Synchronisation
Pour la deuxième partie, les deux modules principaux pour cela sont, comme vous le suggérez, Feeds et Migrate .
La différence entre Feeds et Migrate est que Feeds est conçu pour l'importation régulière de contenu, tandis que Migrate est conçu pour le portage unique de contenu d'un endroit à un autre. Migrate prend en charge la mise à jour des données existantes, mais étant donné que les deux modules sont bien pris en charge, il est plus logique d'utiliser le module qui a été créé pour la tâche à accomplir - Les flux sont une meilleure correspondance.
Ayant utilisé les deux modules moi-même (flux pour la synchronisation, migration pour la migration), je ne trouve pas que les flux soient plus compliqués que la migration. La migration a nécessité plus de code personnalisé dans mon expérience, bien que la migration de sites entiers soit plus complexe que l'importation de types de contenu uniques, il est donc difficile de comparer.
4. Module personnalisé pour le stockage à distance, la synchronisation et la mise en cache
Il existe un certain nombre de modules qui peuvent vous aider dans cette tâche.
Vous avez mentionné le module Données des services Web et d'autres ont mentionné le module Données . Une autre option à considérer est le module API d'entité distante . Notez que le seul de ceux que j'ai expérimenté est le module Data.
Le module de données des services Web n'a pas encore de version - ce qui peut indiquer que le code n'est pas encore stable, l'API peut changer, etc. Il ne prend pas en charge les requêtes de champ d'entité (selon sa page de projet), et une navigation rapide dans le référentiel de code ne montre aucune preuve qu'il prend en charge les vues - vous ne seriez donc pas en mesure d'utiliser des vues pour afficher vos entités;
D'après mon expérience, le module Données est davantage orienté vers les non-développeurs qui ont des données dans une table et qui souhaitent les exposer à des vues. J'ai trouvé la version Drupal 6 assez frustrante à utiliser - même si cela a peut-être changé depuis;
Le module API d'entité distante semble assez prometteur - il prend en charge la récupération et la mise en cache des entités distantes et prend en charge les vues. Ce n'est que sur la version alpha - donc l'API pourrait encore changer. À première vue, il ne semble pas non plus prendre en charge Entity Field Query, et il ne prend en charge qu'un seul type de service distant, vous devez donc implémenter le vôtre.
Conclusion
Étant donné qu'aucun des modules de stockage à distance ne prend en charge les requêtes de champ d'entité, l'utilisation des entités + flux réels est la solution qui vous donnera la meilleure intégration avec votre site Drupal.
Si la prise en charge de Views est suffisante et que vous ne vous inquiétez pas d'une intégration potentielle avec d'autres modules via Entity Field Queries, l'utilisation de l'API d'entité distante peut être la voie à suivre - vous devez cependant implémenter votre propre interface distante.