Scroll
JSON:API とコアのRESTモジュールの比較
TL;DR
公開したいエンティティ以外のデータがある場合はRESTを選択してください。それ以外の場合は、JSON:APIを選択してください。
もう少し詳しく説明すると：
- コアのRESTモジュールはあらゆること（任意の形式、任意のロジック、任意のHTTPメソッド）と極めて高い設定自由度を可能にします。強力ですが複雑であり、そのため比較的壊れやすいものになります。
- JSON:APIは、Drupalの最大の強み（エンティティ／データモデリング）を一貫した方法で公開することに焦点を当てています。シンプルでありながら、ほとんどのユースケースで十分なパワーを持っています。
機能の比較表
| 機能 | JSON:API | REST | 備考 |
|---|---|---|---|
| リソースとして公開されるエンティティ | ✔️ | ✔️ | REST：エンティティタイプごとに設定が必要。JSON:API：デフォルトですべて公開。両方：エンティティアクセスを尊重。 |
| リソースとして公開されるカスタムデータ | ✔️ | カスタムの@RestResourceプラグインを作成する。JSON:APIはエンティティのみをサポートします。 | |
| 個々のリソースの取得 | ✔️ | ✔️ | |
| リソースリストの取得 | ✔️ | ある程度（kinda） |
REST：ビューを設定し、「RESTエクスポート」ディスプレイをセットアップする必要があります。 |
| リソースリストのページング | ✔️ | Pager Serializerのような追加モジュールが必要です。 | REST：非対応！RESTエクスポートビューはすべてのリソースを返します。 |
| リソースリストのフィルタリング | ✔️ | ある程度（kinda） |
REST：すべてのフィールドと、すべての可能な演算子に対して公開フィルターを作成した場合のみ |
| リソースのソート | ✔️ | ||
| インクルード／埋め込み | ✔️ | HAL+JSONのみ | |
| フィールド値の不要なラッピングがないこと | ✔️ | HAL正規化もデフォルトの正規化も（したがってすべての形式も）、Drupalが使用するメモリ内のPHPデータ構造をそのまま公開してしまうため、コンシューマーにとって苦痛なDXになります。JSON:APIは、単一カーディナリティで単一プロパティのフィールドの正規化を簡素化します。 | |
| コンシューマーが不要なフィールドを省略できること | ✔️ | ||
| 一貫したURL | ✔️ | ||
| コンシューマーが利用可能なリソースタイプを発見できること | ✔️ | ||
| Drupalに依存しないレスポンス構造 | ✔️ | REST：HAL正規化は理論上Drupal特有の要素を排除していますが、実際にはそうではありません。 | |
| クライアントライブラリ | ✔️ | ||
| 拡張可能な仕様 | WIP | ||
| ゼロ設定 | ✔️ | REST：各@RestResourceプラグイン定義は公開可能ですが、公開するために設定する必要があります。それぞれについて、許可される形式、許可される認証プロバイダー、および任意で許可されるHTTPメソッドまで選択する必要があります。 JSON:API：すべてのエンティティが自動的に公開され、エンティティ／フィールドアクセスが尊重され、インストール済みのすべての認証プロバイダーが自動的に許可されます。 |
詳細情報
JSON:APIモジュールをDrupalコアに追加した根拠と、モジュールアーキテクチャの根拠を参照してください。
Drupalドキュメントからの記事です。