現在のデータを配信するRESTサービスを作成する必要があります。
getNode(nid) ->すべてのノードフィールド ->フィールドがエンティティ参照の場合(ファイル、人間が読めるURLなど) ->サブフィールドを含める ->フィールドが段落のタイプの場合、サブフィールドを人間が読める形式で再度含めます
Drupalは、IDで参照されるコンテンツのすべての平和のために新しいリクエストを作成する必要がない限り、まだRestの準備ができていません。
たとえば、Pinterestの壁のような出力があります。各項目は段落要素を使用して作成されます(分類法などの他の参照を使用する場合があります)
クリーンなjsonリストが必要です。段落、ファイル、または分類の参照などのネストされた要素が欠落することなく正しく構造化されています。この瞬間、参照された要素のIDを取得します。
この壁のすべてのデータを収集するには、100以上のリクエストを呼び出す必要がありますか?
1)または、ノードを収集するためのリクエストを1つ作成する必要があります。
2)すべての第1レベルのエンティティー参照を収集するための別の要求。その後、それらを配列に格納します。
3)その後、第2レベルのエンティティ参照をリクエストします。
オーバーヘッドと時間についての質問になると、これは私には恐ろしいようです。
もちろん、私はこの問題に役立つはずのいくつかのモジュールをチェックアウトしました:
段落エンティティタイプでは機能しないrest_export_nestedモジュール
rest_viewsはフィールドをjsonではなくhtmlとして出力するようです。これまでのところ、実際の解決策はありません。
じゃあ何をすればいいの?別の方法は、[NODE_ID]のターゲットIDを持つ段落のビューを作成することです。しかし、これは第1レベルの段落でのみ機能します。ネストされたパラグラフでも問題は存在します。
独自のRESTサービスを作成するカスタムモジュールを作成する唯一の方法は本当にありますか?
JSON APIは、これまでに見たことのない別のソリューションでしょうか?
任意の入力を歓迎します。ありがとう。
いいえ。コアREST&RESTここではビューは適切なソリューションではありません。このためのカスタムモジュールは必要ありません。
あなたが言及したように、JSON APIモジュールは 単一のリソース要求でのエンティティ参照 の包含をサポートしています。要求された各エンティティにはrelationships
というプロパティがあり、これはinclude
パラメータを介して含めることができる他のエンティティへの参照です。参照内の参照(例:メディアエンティティを参照するノード、ファイルエンティティを参照するノード)もサポートされますが、参照を追跡するためのいくつかの作業(たとえば、与えられたinclude
プロパティを介して要求を含める場合)配列プロパティincluded
。これは、まだidで並べ替える必要があります)。
Drupalエンティティ参照に続くAPIwithinが返されたエンティティオブジェクトを探す)を探している場合は、GraphQLを使用する必要がありますモジュールは、エンティティ参照を必要に応じて拡張できる独自のデータ仕様を定義できるようにするためです。