Drupal 7？
Drupalにリモートデータ構造を統合するためのいくつかの戦略を見てきました。特定のモジュールが安定し、ユースケースが試されたため、戦略は進化しているようです。
REST API。IDを介して公開されるいくつかのデータタイプ（market、market_hours、vender、stall、produce）などで表されるデータ構造 "Farmers Markets"があるとします。外部サービスはDrupalで関連付ける必要があります。つまり、「market」をロードするときは、「market_hours」と「stall」からデータを取得する必要があります。これを=で読み取り専用コンテンツとして表すための最良の方法は何ですか。 Drupal定期的に同期されますか？
私はこれを次の基準で評価しようとしています：
Drupalのデータ構造：
ノードとカスタムエンティティ
私が見たWebサービスに関連するいくつかのシナリオでは、カスタムエンティティを使用しています。 CRUD演算を簡素化します。ただし、これらのアイテムは公開されているため、「コンテンツ」です。
ストレージ（ローカルvsリモート）：
サービスがリモートエンティティとして読み込まれる例をいくつか見ましたが、このモジュールは https://drupal.org/project/wsdata のライブラリを作成します。これは最も魅力的に聞こえますが、多くのユースケースを見ていません。カスタムコードの例もあります： https://drupal.org/sandbox/fago/149318
データの同期：
フィードvs移行vsグズルvs「Webサービスクライアント」vs「Webサービスデータ」
いくつかのオプションがあります。フィードでエンティティがサポートされるようになりました。特にカスタムシナリオの場合、移行はフィードよりもずっとクリーンに見えます。リモートサービスとの同期を取得するためにguzzleクライアントを使用している人々も見ました： http://drupalcode.org/project/ckan.git/blob/refs/heads/ckan_dgu_7.x-1.x:/ ckan.drush.inc＃l27 。 WSクライアントモジュール https://drupal.org/project/wsclient は、特にレストクライアントとして作成されたオプションを提供することにも気付きました。 Webサービスデータはサービスから直接読み込まれ、ローカルにキャッシュされます。
ご意見をお寄せいただきありがとうございます。
1.質問を再定式化する
あなたの例は、データがDrupal側で、一方向の同期のみで読み取られることを示しています。これは、ここで考慮すべき最も重要な要素だと思います。リモートストレージ、同期、ローカルキャッシングのバリアントである-ローカルキャッシングが最終的にDrupalデータベースのエンティティになる場合でも.
したがって、「ローカルストレージとリモートストレージ」ではなく、次のような疑問が生じます。
- データをローカルでキャッシュする必要があります。
- データを実際のエンティティとしてキャッシュし、フィード（または同様のもの）を使用してデータを定期的に同期する必要があります。または
- 同期とキャッシングを提供するカスタムメイドのモジュールを使用する必要があります。
興味のある記事は、「 Drupal 7）のリモートエンティティ 」にあります。
2.データをキャッシュする
一般的に、データをキャッシュすることは良い考えです：
他のサービスの停止、または接続のタイムアウトから保護されます。
Drupalデータベースにデータが存在すると、操作が高速化されます。
Drupalデータベースにデータが存在することは、ビューなどの他のモジュールと統合される可能性が高くなることを意味します（ただし、これは保証されません）。
データをキャッシュしない唯一の利点は、古くなったデータを取得しないことです。これは、場合によっては好ましいことです。古くなったデータではなく、データを表示しない方が望ましい場合もあります。私はこれをあなたが与えた例の利点とは考えていないので、この答えはローカルキャッシュを含むソリューションに焦点を当てます。
3.ローカルエンティティ+同期
ローカルエンティティを用意して自分で同期するオプションを選択すると、元の質問に戻ります。
ノードまたはカスタムエンティティを使用する必要があります。
同期に最適なモジュール。
3.1ノードとカスタムエンティティ
正確にノードとは何かの定義は、非常にオープンなものです。 ノードのドキュメントページ は、ノードが「投稿」され、サイトに「保存」されていることを示しています。どちらもデータには適用されません。
Drupal開発者として、何かがノードであれば、サイト自体でそれを操作できるはずです。
Drupalユーザーの場合、同様にノードを編集できると思います。
このDrupal 8 issue https://drupal.org/node/2019031 は、「読み取り専用」の概念がエンティティレベルで適用される概念であることを示唆しています。バンドルレベルではなく、これが実装された場合、このルートをたどることでメリットを得られます。
要約すると、あなたのデータは読み取り専用であり、リモートで保存されているそれはより多くのことをしますデータを表すためにカスタムエンティティタイプを使用する意味があります。
3.2同期
2番目の部分の場合、このための2つの主要なモジュールは、ご提案のとおり、 Feeds および Migrate です。
FeedsとMigrateの違いは、Feedrateはコンテンツを定期的にインポートするために構築されているのに対し、Migrateはコンテンツをある場所から別の場所に1回だけ移植するために構築されていることです。 Migrateは既存のデータの更新をサポートしますが、両方のモジュールが適切にサポートされていることを考えると、手元のタスク用にビルドされたモジュールを使用する方が理にかなっています。フィードの方が適しています。
両方のモジュールを自分で使用した（同期のためのフィード、移行のための移行）フィードが移行よりも厄介であるとは思いません。サイト全体を移行することは、単一のコンテンツタイプをインポートするよりも複雑であるため、移行ではより多くのカスタムコードが必要でした。比較するのは困難です。
4.リモートストレージ、同期+キャッシュ用のカスタムモジュール
このタスクに役立つモジュールがいくつかあります。
Webサービスデータ モジュールについて言及しましたが、他の人は データモジュール について言及しています。考慮すべきもう1つのオプションは Remote Entity APIモジュール です。私が経験したものはDataモジュールだけです。
Webサービスデータモジュールにはまだリリースがありません。これは、コードがまだ安定していないこと、APIが変更されていることなどを示している可能性があります。 （そのプロジェクトページによると）エンティティフィールドクエリはサポートされていません。コードリポジトリをすばやく参照しても、ビューがサポートされているという証拠はありません。そのため、ビューを使用してエンティティを表示することはできません。
私の経験では、Dataモジュールは、テーブルにデータがあり、それをビューに公開したい非開発者向けです。私はDrupal 6バージョンを使用するのは非常に苛立たしいことです-それ以降変更されている可能性がありますが）。
リモートエンティティAPIモジュールは非常に有望に聞こえます。リモートエンティティのフェッチとキャッシュをサポートし、ビューをサポートしています。これはアルファ版リリースのみです-したがって、APIは変更される可能性があります。一見、Entity Field Queryもサポートしていないようで、1種類のリモートサービスしかサポートしていないため、独自のリモートサービスを実装する必要があります。
結論
どのリモートストレージモジュールもエンティティフィールドクエリをサポートしていないため、実際のエンティティ+フィードを使用することが、Drupalサイトとの最適な統合を実現するソリューションです。
ビューのサポートで十分であり、エンティティフィールドクエリを介した他のモジュールとの統合の可能性を心配していない場合は、リモートエンティティAPIを使用する方法が考えられます。ただし、独自のリモートインターフェースを実装する必要があります。
Field Storage API があります。これにより、デフォルトのデータベースエンジン以外のプラグイン可能なストレージバックエンドが可能になります。
ビュー、ルール、トークン、クッドフック、検索API、およびシステムの統合が間違いなく必要な場合、それらはノードと見なすことはできませんが、データベースに「エンティティID」と「外部ID」関係と、「エンティティプロパティ」にカプセル化された取得情報呼び出し。最後に、データを同期するためにどのツールを選択しても、私はそれをcronキューで処理します。
データを時間どおりに取得して公開する必要がある場合は、外部データを取得するためのインターフェイスクラスを作成し、「ファーマーズマーケット」構造から情報を取得するクラスを使用してこのインターフェイスを実装することをお勧めします。
よろしく