構造化コンテンツ配信および管理用のAEM API aem-apis-structured-content-delivery-and-management

コンテンツフラグメント配信用AEM REST OpenAPI

• この API は、AEMのコンテンツフラグメントから構造化コンテンツを配信するための JSON 応答を作成します。
• エンドポイントとしてコンテンツフラグメントへのパスを使用します。
• この API は REST ベースです。
• CDN 統合を含むコンテンツ配信用に最適化されています。

コンテンツフラグメント配信用のAEM GraphQL API

• この API はスキーマベースです。 API スキーマは、コンテンツ構造を定義するコンテンツフラグメントモデルで表されます。
• この API はGraphQL ベースです。

コンテンツフラグメントおよびコンテンツフラグメントモデルの OpenAPI

• これらの API は、構造化コンテンツ管理を目的としています。
• それぞれのGET演算子は、コンテンツ配信用に最適化されていません。
• この API は REST ベースです。

AEM Assets HTTP API での コンテンツフラグメントのサポート

• AEMの構造化コンテンツ配信用の JSON 出力のオリジナル API。
  • 堅牢で実証済みですが、この API では JSON 出力を 完全にハイドレート することはできません。 参照はパスとしてのみ出力され、それ以上のコンテンツを取得するにはセカンダリ API リクエストが必要です。
• Assets HTTP API は、コンテンツフラグメントとコンテンツフラグメントモデル（CRUD）の管理にも使用できます。
• この API は REST ベースです。
• Assets HTTP API でのコンテンツフラグメントのサポートは、今後、廃止される予定です。これは、Edge Delivery Services JSON REST API によって継承されるためです。 タイムスケールはまだ決まっていません。

シンプル

• 開発者は（多くの場合） HTTP と REST に精通しています。 API レポートのPostmanの状況によると、REST を使用している開発者の割合が高くなっています。

• シンプルさは、親しみやすさをもたらします。 REST の場合、誰がクエリを所有し、誰がアプリを所有するかという組織的な質問はありませんが、これらの質問はGraphQLで発生する可能性があります。

• （通常は）慣れることで、幅広いコミュニティとツールの風景が得られます。 GraphQL固有の欠点ではありませんが、REST にとってより広く、より深い可能性があります。

• また、よりシンプルなアプローチにより、セキュリティの実装も容易になります。 REST では、レンダリングするコンテンツを決定するフィルタリングはすべてクライアントアプリで行われます。 GraphQLでは、これはクライアントとサーバーの間のスキーマベースのクエリで行われます。

柔軟性

• REST を使用すると、開発者は任意のリソース GET 使用できます。 GraphQLを使用すると、スキーマ内で定義されたリソースに制限されます。

キャッシュ

• REST GET リクエストに対する JSON 応答は、本質的にキャッシュ可能です。 GraphQL POST リクエストは、作成されない限りキャッシュできません。例えば、サーバーに保存され、REST のような GET リクエストでリクエストされるAEM永続クエリを使用する場合などです。

コンテンツ配信の効率

• フォーカス

  • GraphQLを使用すると、クライアントアプリケーションは、レンダリングに必要な正確なコンテンツをリクエストでき、それ以上はリクエストできなくなります。 このアプローチは、コンテンツの過剰配信、過剰なコンテンツペイロードおよび不要な帯域幅消費を防ぎます。

• 単一のエンドポイント

  • REST では、すべての API リクエストがエンドポイントですが、GraphQLでは共通のエンドポイントは 1 つだけで、異なるコンテンツリクエストがその共通のエンドポイントを使用したクエリとして表現されます。

ラピッドプロトタイピング

• GraphQLの場合、これは 1 つの手順でGraphQLのクエリと統合されたプロセスであり、プロトタイプ作成が容易になります。 一方、REST のプロセスは 2 ステップです。

  1. API を使用してコンテンツを取得します。
  2. JSON 応答で、クライアントアプリでのレンダリングに使用する内容を決定します。