Salesforce 認定 MuleSoft Platform アーキテクト 無料問題 4 / 10 ・ 分野4: システム層、プロセス層、エクスペリエンス層を用いた API 設計
モバイルアプリのチームは、顧客・注文・在庫の各 API にまたがるデータを使う画面を、要件が出るたびに作っている。データの取り出し方を見直すため、Anypoint DataGraph を検討している。DataGraph の働きとして、ドキュメントの説明に合うものはどれか。
- 追加した API のスキーマを統合スキーマにつなぎ、1つの GraphQL エンドポイントで問い合わせさせる
- 選んだ API ごとに GraphQL のラッパーになる Mule アプリを生成し、各 API の前にデプロイする
- 各 API の RAML を1つの仕様に統合した REST API のアセットを作り、Exchange で共有する
- 各 API の応答を組み合わせるフローを生成し、新しいエクスペリエンス層の API として公開する
正解と解説を見る
正解: A
正解の理由
DataGraph の頁は、アプリケーションネットワークに API を足すたびに Anypoint Platform がそれをメタデータのグラフとして持ち、DataGraph がそれらのグラフを1つの統合スキーマにつなぐと書く。統合スキーマは1つの SaaS の GraphQL エンドポイントとして動き、すべての API の項目を含んでつなぐので、利用者は下の API の関係を知らなくても API をまたいで問い合わせられる。
違う選択肢
「選んだ API ごとに GraphQL のラッパーになる Mule アプリを生成し、各 API の前にデプロイする」… DataGraph は API ごとに Mule アプリを生成してデプロイするものではない。API のスキーマを統合スキーマにつなぎ、1つのエンドポイントとして動かす。
「各 API の応答を組み合わせるフローを生成し、新しいエクスペリエンス層の API として公開する」… 頁は DataGraph の利点として、新しいコードを書かずにアプリケーションネットワークの情報を見つけ、再利用し、提供できることを挙げる。要件ごとに新しい API を作る形ではない。
「各 API の RAML を1つの仕様に統合した REST API のアセットを作り、Exchange で共有する」… DataGraph がつなぐのは各 API のスキーマで、結果は REST API の仕様ではなく、GraphQL のエンドポイントとして問い合わせる統合スキーマである。
押さえどころ
統合スキーマは、DataGraph に足したいろいろな API のスキーマから型を集めた、常に最新の1つのまとまりである。統合スキーマの問い合わせの型は、足した API のスキーマの問い合わせのメソッドをすべて含むので、利用者は使えるデータを1か所で確かめ、必要な部分だけを1回の問い合わせで受け取れる。