1. Reformulando a pergunta
Seu exemplo sugere que os dados são somente leitura no lado do Drupal, apenas com sincronização unidirecional. Acho que esse é o fator mais importante a ser considerado aqui, porque, na verdade, qualquer solução que você implemente será uma variante de armazenamento remoto, sincronização e cache local - mesmo que o cache local acabe sendo entidades no banco de dados Drupal.
Portanto, a questão, em vez de ser "armazenamento local versus armazenamento remoto", será:
- Você deve armazenar em cache os dados localmente;
- Você deve armazenar em cache os dados como entidades reais e usar Feeds (ou similares) para sincronizar os dados regularmente; OU
- Você deve usar algum módulo personalizado que forneça a sincronização e o cache.
Um artigo em que você pode estar interessado está em " Entidades remotas no Drupal 7 ".
2. Armazenando em cache os dados
Em geral, armazenar em cache os dados é uma boa ideia:
Você está protegido contra interrupções nos outros serviços ou tempos limite na conexão;
Ter seus dados presentes no banco de dados do Drupal acelerará as operações;
A presença de seus dados no banco de dados Drupal significa que é mais provável que você obtenha integração com outros módulos, como Views (embora isso não seja garantido).
A única vantagem de não armazenar em cache os dados é que você nunca obtém dados obsoletos, o que em alguns casos é preferível - às vezes é preferível não exibir dados em vez de dados obsoletos. Não vejo isso como um benefício no exemplo que você deu, portanto, focarei esta resposta em uma solução que envolve o cache local.
3. Entidades locais + Sincronização
Se você optar por ter entidades locais e sincronizá-las você mesmo, voltaremos às suas perguntas originais:
3.1 Nós x entidades personalizadas
A definição do que exatamente é um nó é bastante aberta. A página de documentação nos nós sugere que os nós estão "postando" e "armazenados" no seu site - nenhum dos quais se aplica aos seus dados;
Como desenvolvedor do Drupal, eu esperaria que, se algo fosse um nó, eu pudesse manipulá-lo no próprio site;
Como usuário do Drupal, eu também esperaria que os nós pudessem ser editados;
Esta edição do Drupal 8, https://drupal.org/node/2019031, sugere que o conceito de "somente leitura" é aquele que se aplicaria no nível da entidade e não no nível do pacote. Se isso for implementado, você se beneficiará disso por seguir esse caminho.
Para resumir: seus dados sendo somente leitura e armazenados remotamente , faz mais sentido usar um tipo de entidade personalizado para representar seus dados.
3.2 Sincronizando
Para a segunda parte, os dois módulos principais para isso são, como você sugere, Feeds e Migração .
A diferença entre Feeds e Migrate é que os Feeds são criados para a importação regular de conteúdo, enquanto o Migrate é criado para a transferência única de conteúdo de um lugar para outro. O Migrate suporta a atualização de dados existentes, no entanto, como os dois módulos são bem suportados, faz mais sentido usar o módulo que foi criado para a tarefa em questão - os feeds são uma correspondência melhor.
Tendo usado os dois módulos eu mesmo (Feeds para sincronização, Migrando para migração), não acho que os Feeds sejam mais confusos do que Migrar. Migrar exigiu mais código personalizado em minha experiência, embora a migração de sites inteiros seja mais complexa do que a importação de tipos de conteúdo únicos, por isso é difícil comparar.
4. Módulo personalizado para armazenamento remoto, sincronização + cache
Existem vários módulos por aí que podem ajudar nessa tarefa.
Você mencionou o módulo Dados dos Serviços da Web e outros mencionaram o módulo Dados . Outra opção a considerar é o módulo da API de entidade remota . Observe que o único daqueles com quem tenho experiência é o módulo Dados.
O módulo Dados de Serviços da Web ainda não possui uma liberação - o que pode indicar que o código ainda não está estável, a API pode mudar e assim por diante. Ele não suporta consultas de campo de entidade (de acordo com a página do projeto) e uma rápida navegação no repositório de códigos não mostra evidências de que ele tenha suporte a Views - portanto, você não poderá usar o Views para exibir suas entidades;
O módulo Dados é mais orientado, na minha experiência, para não desenvolvedores que possuem dados em uma tabela e desejam expô-los a visualizações. Eu achei a versão do Drupal 6 bastante frustrante de usar - embora isso possa ter mudado desde então;
O módulo da API de entidade remota parece bastante promissor - suporta a busca e o cache de entidades remotas e possui suporte a Views. É apenas na versão alfa - portanto, a API ainda pode mudar. À primeira vista, também não parece ter o suporte a Consulta de Campo de Entidade, e suporta apenas um tipo de serviço remoto, portanto você precisaria implementar o seu próprio.
Conclusão
Como nenhum dos módulos de armazenamento remoto suporta consultas de campo de entidade, o uso de entidades + feeds reais é a solução que fornecerá a melhor integração com o site Drupal.
Se o suporte a Views for suficiente e você não estiver preocupado com a possível integração com outros módulos por meio de consultas de campo de entidade, o uso da API de entidade remota pode ser o caminho a seguir - você precisará implementar sua própria interface remota.