Mulesoft学習記【三日目】
前書き
三日目です(´・ω・`)ノ
昨日Anypoint Platformの各機能をざっと触り、概要の把握はできた気がします。
今日はAPIのデザイン→ビルド→デプロイ→管理という流れを一通りハンズオンで学ぶ予定。
本日の学習内容
Anypoint Platform Development: Fundamentals(Mule 4)のSection3~5(APIのデザイン→ビルド→デプロイ→管理)
APIデザインにおけるspec driven developmentの考え方
RAML(Restful API Modeling Language)を用いたAPI specificationの作成方法
API specificationの公開方法(=API portalの作成方法)
Anypoint Studioの使い方
Anypoint Studioを用いたAPI仕様書およびMuleアプリケーションの作成方法
Muleアプリケーションのデプロイ方法
API Managerを用いたAPIプロキシの作成&デプロイ方法
APIのデザイン
一般にAPIデザインの手法として以下のものが挙げられる。
- 手動でコーディング
- Apiary.ioなどのAPI Blueprint
- Open API Spec
- RAML
Mulesoftの場合、(RESTful APIに関しては)RAMLを用いてAPI DesignerからAPI Specificationを作成する。
そしてそれをAPI portalで公開するノ
API仕様書において重要なのは、それによってAPIの振る舞いを読者に理解可能にすることであり、具体的には下記の情報を最低限記載する必要がある。
- どのような種類のリクエストを受け付けるのか
- どのようなレスポンスを自身が返すのか
- 項目やデータ型に関する情報(どの項目が必須なのかなど)
RAMLの場合、具体的に下記の情報を記す。
- リソース
- HTTPメソッド
- リクエスト内容
- レスポンス内容(HTTPステータス情報を含む)
↓MulesoftのAPI Designer

APIのビルド
RAMLを用いてAPI Designer(or Anypoint Studio)からAPI Specificationを作成したら、Flow Designer(or Anypoint Studio)でMuleアプリケーションを作成していく。
Mule4のMule EventはMule Message(Payload+Attributes)とVariablesで構成される。

- Payloadはメッセージの具体的な中身で上書可能。
- Attributesはクエリパラメータやファイルサイズといったメタデータで上書不可。
- Variablesはアプリケーションをまたいで利用可能な変数
フローは大きく①ソース②プロセス③エラーハンドリングの三つの要素で構成される。
ソースの欠如したフローを一般にプライベートフローと呼ぶ。
ソースとエラーハンドリングの両方が欠如したフローをサブフローと呼ぶ(※エラー処理はフローまたはプライベートフローに依存する)
プライベートフローまたはサブフローはフロー参照ないしDataWeave参照から呼び出される。
API Toolkitプラグインを利用するとRAMLのAPI仕様書から自動でAPIインターフェースを生成できる。
データへのアクセス・データの変換にはDataWeave2.0という言語(「Transform Message」コンポーネント)を用いる。
↓Anypoint Studioの画面。開発してる感があり、テンションが上がる。

APIのデプロイと管理
下記のステップでAPIのデプロイと管理を行う。
- Runtime ManagerでAPIをデプロイする。
- ProxyアプリケーションをAPI Managerで作成&デプロイ(→ポリシー生成)
- APIの利用状況をAPI Managerで監視
APIプロキシはWebサービスへのアクセスをAPIゲートウェイで制限する仕組み
APIゲートウェイはAPIを受け付ける窓口なるruntimeのこと
↓API Manager

本日の気付きと疑問点
API仕様書作るのテラメンドスなので、Mulesoftは堅実な性格の人が向いてる気がする。