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

Adobe Experience Manager(AEM)as a Cloud Service では、コンテンツフラグメントからの構造化コンテンツ配信とコンテンツフラグメント管理の両方に対して複数の API を提供します。特定の API について詳しくは、個々のページを参照してください。

  • コンテンツフラグメント配信用の 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 出力を提供しません。参照はパスとしてのみ出力されるので、さらにコンテンツを取得するには 2 番目の API リクエストが必要になります。
    • また、Assets HTTP API は、コンテンツフラグメントおよびコンテンツフラグメントモデル(CRUD)の管理にも使用できます。
    • この API は REST ベースです。
    • Assets HTTP API のコンテンツフラグメントサポートは、Edge Delivery Services JSON REST API によって継承されるので、今後、廃止される予定です。時間スケールは、まだ決定されていません。

REST と GraphQL rest-vs-graphql

使用する API は、開発者が決定します。AEM は両方をサポートしています。

オンラインで多くの比較が使用可能ですが、REST のハイライトとメリットは次のとおりです。

  • シンプルさ

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

    • シンプルさには、親しみやすさが伴います。REST では、クエリの所有者やアプリの所有者に関する組織的な質問は発生しませんが、GraphQL ではこれらの質問が発生する可能性があります。

    • 親しみやすさには(通常)幅広いコミュニティとツール環境が伴います。これは GraphQL 固有の欠点ではありませんが、REST ではより広範囲かつ奥深いものとなる可能性があります。

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

  • 柔軟性

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

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

GraphQL のメリットは次のとおりです。

  • コンテンツ配信の効率

    • フォーカス

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

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

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

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