4
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

amokを使ってさくっとモックAPIを作成してみる

Last updated at Posted at 2015-12-22

前説

qiita、はじめました。乱文になりそうですが、お目こぼしのほどよろしくお願いいたします。

なお本記事は、Enterprise APIs Advent Calendar 2015の12月22日担当分として書かせていただいております。
こちらも初参戦です。今までOpenCVやSublimeやLaTeXなどAPIには関係ない様々なAdvent Calendarにはお世話になってきたので、書く側に回るとなると感慨深いものがあります。

はじめに

バックエンドのAPIが完成していないという場合、自分たちの開発を止めるのではなくモックを用意するというのが常套手段だと思います(と聞いています)。世の中には既にswaggerなどのドキュメントとモックの作成を兼ね備えた便利ツールが出まわっております。しかし、割と学習コストが高く感じます。そこで、ぱぱっとつくれるモックはないかということで、今回はamokを紹介いたします。

amokとは?

Github上で公開されている(api-bucket/amok · GitHub)モック作成プログラムです。こうして、紹介記事を書かせていただいているところ申し訳ないのですが、公式のドキュメントが割と充実しているので、READMEを読んでいただければだいたい分かるかとは思います。取り敢えず、以下ではREADMEを参考にamokでモックAPIを作成しようと思います。

amokのダウンロード

  1. amokのDL
    api-bucket/amok · GitHubからダウンロードします。
    GUIから「Download ZIP」を選択しても、gitコマンドでもどちらでも構いません。

  2. 中身の確認
    amok-masterの中身はこのようになっております。

     amok-master
     ├── LICENSE
     ├── README.md
     ├── examples
     │   ├── apigee-amok
     │   │   ├── README.md
     │   │   ├── apiproxy
     │   │   │   ├── mock.xml
     │   │   │   ├── proxies
     │   │   │   │   └── default.xml
     │   │   │   └── targets
     │   │   │       └── node.xml
     │   │   ├── node
     │   │   │   ├── app.js
     │   │   │   ├── controller.js
     │   │   │   ├── node_modules
     │   │   │   │   └── zip.xml
     │   │   │   ├── package.json
     │   │   │   └── responses
     │   │   │       ├── about
     │   │   │       ├── html
     │   │   │       ├── json
     │   │   │       ├── payment
     │   │   │       ├── soap
     │   │   │       ├── xml
     │   │   │       ├── xml_error1
     │   │   │       └── zip.xml
     │   │   ├── pom.xml
     │   │   └── tests
     │   │       ├── integration
     │   │       │   ├── FuncionalTests.feature
     │   │       │   └── step_definitions
     │   │       │       ├── apickli-gherkin.js
     │   │       │       └── mock.js
     │   │       └── package.json
     │   └── standalone-amok
     │       ├── README.md
     │       ├── app.js
     │       ├── controller.js
     │       ├── package.json
     │       └── responses
     │           ├── about
     │           ├── html
     │           ├── json
     │           └── xml
     └── source
     	├── LICENSE
     	├── README.md
     	├── amok.js
     	├── generate-npm.sh
     	└── package.json
    
     14 directories, 36 files
    

    以前は、この中のexamples/apigee-amokのみを配布しておりましたが、2015/12/22現在では利用例の一部となって、主となるモック部分のソースをメインとして公開しているようです。そのため利用例としてexamples/standalone-amokも追加され、自身でNode.jsサーバを保持している方であればApigeeに依存することなくサンプルアプリを起動するだけでモックAPIを作成することができるかと思います。

    今回は、サーバサイドの知識なしにApigee上にモックを作成できるapigee-amokをそのまま利用してモックを作成しようと思います。

事前準備

  1. mavenを導入

    brew install maven
    

    ローカルで編集したproxyをEdgeにデプロイするとき使用します。

  2. Apigeeに登録
    こちらのApigeeの登録ページからアカウントを登録してください。後に必要となるので、以下の3つはチェックしておいてください。

    • ユーザ名(メールアドレス)
    • パスワード
    • 環境(org)名

apigee-mokの使い方

  1. 返したいレスポンスをamok-master/examples/apigee-amok/node/responsesディレクトリに保存します。サンプルという立ち位置のファイル群なので、既にレスポンスサンプルが7パターン用意されております。例えば「json」は、

    • amok-master/examples/apigee-amok/node/routes/json

        {
          "array": [
            1,
            2,
            3
          ],
          "boolean": true,
          "null": null,
          "number": 123,
          "object": {
            "a": "b",
            "c": "d",
            "e": "f"
          },
          "string": "Hello World"
        }
      

    このようにただ、ファイルの中にレスポンス内容を記載しているだけです。ただしここで大事になるのが、ファイル名です。このファイル名が後にAPIの接尾語になります(今回の場合は上記のレスポンスを得たければhttp://{URL}/{basepath}/jsonというAPIを叩くことになる)。そのため、ファイルに記載したレスポンス内容に即したファイル名をつける必要があります。定義したレスポンス内容がユーザ情報なのにファイル名がkeyだったりしたら格好がつきませんので注意してください。

  2. デプロイ

    • ただ、レスポンス内容をファイルに保存しただけであとはデプロイすればモックAPIができてしまいます。早速環境整備の際に用意したmavenを利用してデプロイしようと思います。

    • test env

        mvn install -Ptest -Dorganization={デプロイ先のorg名} -Dusername={Edgeのユーザネーム} -Dpassword={Edgeのパスワード}
      
    • prod env

        mvn install -Pprod -Dorganization={デプロイ先のorg名} -Dusername={Edgeのユーザネーム} -Dpassword={Edgeのパスワード}
      

    これにより、Node.jpアプリのモックProxyがEdge上にデプロイされます。簡単!

  3. 実際にモックAPIを叩いて見たいと思います。
    basepathは今回の手順では変更していないので、デフォルトのhttp://{URL}/amok-api/{ファイル名}を叩くとamock-master/node/routesに保存したレスポンス内容が返ってくるかと思います。

    •   http://importantorganization-test.apigee.net/amok-api/json
      

      を叩くと、上記のレスポンスが200OKで返ってくる

  4. レスポンスコードを変えたいときは、リクエストヘッダに

     x-mock-response-code: XXX
    

    を追加する。

    •   http GET 'http://importantorganization-test.apigee.net/amok-api/json' "x-mock-response-code: 500"
      

      を叩くと、上記のレスポンスが500 Internal Server Errorとして返ってくる

  5. URLを変えずにエラーレスポンスを返却したいときは、リクエストヘッダに

     x-mock-type: YYYY
    

    を追加する。

    •   http GET 'http://importantorganization-test.apigee.net/amok-api/xml' "x-mock-type: _error1"
      

      を叩くと、examples/apigee-amok/node/routesに保存したファイルのうち、「xml」ファイルではなく「xml_error1」ファイルの内容を200OKとして返すようになる。

まとめ

このように、ただ同一のレスポンスを返すモックなのではなく、レスポンスコードの変更やエラーレスポンスに関しても柔軟に対応することができ、なおかつ簡単にモックAPIを作成できる、amokを紹介させていただきました。

今回紹介したapigee-amokの例ではApigeeのGUI上からamok-master/examples/apigee-amok/node/routes以下のファイル(=レスポンスパターンの定義ファイル)の追加/変更/削除はできません。レスポンス内容を弄りたいときは、ローカルで編集し、再びデプロイが必要なため割と面倒くさいと感じておりました。
また、amokのProxyはNode.jsアプリなので、後ほどEndpointにURLを指定してアクセスさせるということができません。そのため、後日バックエンドが完成した際にモック用のAPIから、新たにAPI Proxyを作成する必要があります。

と、このような問題を抱えておりますが、簡単にモックAPIが作成できる利点は変えられないものかと思います。また、上記の問題については独自にNode.jsサーバを構築し、standalone-amokのサンプルを利用すれば解決するかと思います。
このように、構築の容易性を重視する方も、拡張性を重視する方にも利用を勧められるものだと思います。

4
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?