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

# 前説


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

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


# はじめに

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

# amokとは？

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

# amokのダウンロード

1. amokのDL
	[api-bucket/amok · GitHub](https://github.com/api-bucket/amok)からダウンロードします。
	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の登録ページ](https://accounts.apigee.com/accounts/sign_up)からアカウントを登録してください。後に必要となるので、以下の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のサンプルを利用すれば解決するかと思います。
このように、構築の容易性を重視する方も、拡張性を重視する方にも利用を勧められるものだと思います。