Salesforce 認定 MuleSoft Integration 基礎 無料問題 6 / 10 ・ 分野4: インテグレーション開発での一般的な技術的複雑さとパターンを説明する
新しい在庫の API を、実装より先に仕様から作る。Anypoint Code Builder の頁「Designing API Specs and Fragments」が示す、API 仕様を設計する流れに合うものはどれか。
- 仕様を Exchange へ公開してから、公開した版だけを取り込んで試し、フラグメントを足す
- 仕様を書いたら Mule のアプリとして実装し、動かせたものを Exchange へ公開する
- フラグメントを先に Exchange へ公開し、それを取り込んでから仕様を書き始める
- 仕様を作るか取り込んで試し、要るときだけフラグメントを足してから Exchange へ公開する
正解と解説を見る
正解: D
正解の理由
Anypoint Code Builder の頁「Designing API Specs and Fragments」は、Anypoint Code Builder を使って新しい API 仕様を作り・設計し・試し・Exchange へ公開すると書き、設計の流れを3つの段で示す。1つめは API 仕様を作るか取り込んで試すこと、2つめは任意（Optionally）でフラグメントを作って仕様に足すこと、3つめは API 仕様を Exchange へ公開することである。仕様は実装を待たずに試し、確かめたものを公開する順になっている。
違う選択肢
「フラグメントを先に Exchange へ公開し、それを取り込んでから仕様を書き始める」… 頁の流れでは、フラグメントは仕様を作って試したあとの2つめの段で、しかも任意である。フラグメントの公開を仕様の前に置く段は無い。
「仕様を Exchange へ公開してから、公開した版だけを取り込んで試し、フラグメントを足す」… 頁は、試すのを1つめの段、Exchange への公開を最後の段に置く。公開を先にして、あとから試す順ではない。
「仕様を書いたら Mule のアプリとして実装し、動かせたものを Exchange へ公開する」… 頁の流れは仕様そのものを Exchange へ公開するまでで、実装の段は入っていない。公開するのは API 仕様である。
押さえどころ
設計を先にする進め方では、仕様が実装の前にできあがり、試してから公開される。フラグメントは、仕様の中で作り、取り込み、参照する部品で、要るときだけ足す。