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のデプロイと管理を行う。

  1. Runtime ManagerでAPIをデプロイする。
  2. ProxyアプリケーションをAPI Managerで作成＆デプロイ（→ポリシー生成）
  3. APIの利用状況をAPI Managerで監視

APIプロキシはWebサービスへのアクセスをAPIゲートウェイで制限する仕組み

APIゲートウェイはAPIを受け付ける窓口なるruntimeのこと

↓API Manager

本日の気付きと疑問点

API仕様書作るのテラメンドスなので、Mulesoftは堅実な性格の人が向いてる気がする。

Mulesoft

Posted by regardie