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