API モック
3分クッキング
2017/03/17 @株式会社FLECT
金森政雄
自己紹介:金森政雄
2016/12/1入社
社会人そろそろ5年目、会社は2社目
前職ではスマホ向けサービスの認証、課金周りを担当
(PM+ブリッジSEみたいな役割)
現在はSalesforceとAWSのSI案件担当中
好きなAWSサービス:APIGateway
アジェンダ
1. APIGateway概要
2. APIモックが必要になった背景
3. モックを作ってみる
4. モックを拡張してみる
5. まとめ
1.APIGateway概要
ServerlessでAPIの入り口になるところ?
最近よく見るServerlessアーキテクチャ
Amazon API
Gateway
AWS
Lambda
Amazon
DynamoDB
Amazon
S3
or
でもそれだけじゃない
APIGatewayはフルマネージドのRESTful APIを提供してくれるサービス
APIのIFとしての機能をフルマネージドで提供してくれる
• APIキャッシュ
• スロットリング
• 認証機構
• ホスティング(Cloud Front上に配置される)
バックエンドは(ほとんど)なんでもOK
• AWS Lambda
• その他各AWSサービス(Kinesis,S3,Dynamoなど)
• HTTPエンドポイント
バックエンドの開発が完了するまでの開発のためにモックの機能を提供
→今回はこちらのお話
2.APIモックが必要になった背景
例えばこんな感じ①
要件:別の開発会社Aが担当しているサービスとの連携機能を開発する
リリース予定:x月15日(話が出たのはx月1日)
API
作りま〜す
クライアント
作りま〜す
開発会社A FLECT
例えばこんな感じ①
要件:別の開発会社Aが担当しているサービスとの連携機能を開発する
リリース予定:x月15日(話が出たのはx月1日)
設計書どうぞ
ありがとうございます!
検証環境はいつできます?
開発会社A FLECT
api.xlsx
例えばこんな感じ①
要件:別の開発会社Aが担当しているサービスとの連携機能を開発する
リリース予定:x月15日(話が出たのはx月1日)
x月13日に
検証環境に反映します
なん、、だと、、?
開発会社A FLECT
どちらも一から作っているのでしょ
うがない。
でもクライアント側はAPIがないと正
直きつい
例えばこんな感じ②
検証環境でのAPI連携テスト設計中
テストのために
こういうデータが欲しいです
開発会社A FLECTtest.xlsx
含異常系
その他諸々
例えばこんな感じ②
検証環境でのAPI連携テスト設計中
ですよね!
開発会社A FLECT
本番環境のデータなので
異常系は難しいですねー
できればこちら側でレスポンスの値
を自由に変更しながらテストしたい
ここまでのまとめ:APIモックが必要になった背景
提携先のAPIの開発が終わるまで待っていられない
• APIの開発が終わってからこちらの開発を進める、ではビジネスのスピードが落ちる
• 開発会社が違うので、ある程度出来上がってからじゃないと触らせてもらえない
提携先の検証環境は自分たちで好きにデータをいじれない
• 元になるデータは提携先のデータ
• 公開されている有名なAPIでもデータを自由に作れないシーンはある
3.モックを作ってみる
3分クッキング:1分目
Swaggerファイルの準備
事前に用意したものがこちらです
3分クッキング:1分目
Swaggerファイルの準備
事前に用意したものがこちらです
{
"swagger": "2.0",
"info": {
"version": "2017-03-13T16:48:46Z",
"title": "MockSample"
},
"host": "vjicotgpwl.execute-api.us-east-1.amazonaws.com",
"basePath": "/dev",
"schemes": [
"https”
], { 以下略 }
3分クッキング:2分目
コマンド実行
$aws apigateway import-rest-api --body 'file:///Users/masakkuma/apimock.json’
{
"name": "MockSample",
"version": "2017-03-13T16:48:46Z",
"id": "yvcu9xxxxx",
"createdDate": 1489506423
}
$aws apigateway create-deployment --rest-api-id yvcu9xxxxx --stage-name dev
{
"id": "dhiyyy",
"createdDate": 1489506649
}
APIの作成
APIのデプロイ
3分クッキング:3分目
コマンド実行
APIにアクセス
https://yvcu9xxxxxl.execute-api.ap-northeast-1.amazonaws.com/dev/test/hoge
{
"message":"Hello APIGateway Mock!"
}
完 成
「事前に用意したもの」解説
APIの作成開始 ※今回は完全に初めてのパターンです
APIの作成
サンプルとしてSwaggerのAPI定義が
設定されている(今回はスルー)
API名と説明を書いて、
「APIの作成」をクリック
リソースの作成①
APIのURLのパスを作成します
リソースの作成②
これを何回か繰り返して
URLを作成する
{domain}/test/hoge
ならtestの下でhogeリ
ソースを作成
※”test/hoge”とすると
{domain}/test-hoge
になってしまう
メソッドの作成①
test/hogeのリソースまで作成したところ
メソッドの作成②
今回はGETメソッドを作成します
保存ボタン忘れがち
メソッドの作成③
Mockを選択する
ここまでの成果
ここまででできたもの
• URL
• 呼出可能なメソッド
これから実際の動作を
定義していきます
統合レスポンスの設定開始
メソッドリクエスト
→リクエスト受付け
統合リクエスト
→リクエストの変換等
統合レスポンス
→レスポンスの変換等
メソッドレスポンス
→レスポンスの設定
統合レスポンスの設定
統合レスポンスの設定
統合レスポンスの設定
統合レスポンスの設定
端っこですがこれが大事
マッピングテンプレートの作成
APIGatewayの肝はここ!!
今回はモックなので、ここに書
いたjsonがそのまま返却されま
す。
実際は、バックエンドのレスポ
ンスをAPIのレスポンスに変換
する設定を記載します。
The ・ ハマりどころ
→使いこなせれば便利
デプロイ
アクセスできるか確認
{
"message":"Hello APIGateway Mock!"
}
Swaggerにエクスポート
デプロイしてしまえば、あとは簡単にエクスポート可能
→再利用したり、別の場所で作ったりも簡単
4.モックを拡張してみる
CORS(Cross-Origin Resource Sharing)対応
目的:ブラウザからajaxでAPIを呼び出したい
問題:ドメインが違うので同一生成元ポリシーを回避する必要がある
CORS(Cross-Origin Resource Sharing)対応
CORS(Cross-Origin Resource Sharing)対応
CORS(Cross-Origin Resource Sharing)対応
アクセスしてヘッダーを確認
ステータスコードを変更する
ついのこの4つの四角を全て使うときがきた
メソッドリクエストでパラメータを定義する
今回はGETメソッドで作っているので、クエリ文字列のパラメータを定義します
統合リクエストでマッピングを定義する
受け取ったパラメータによって、
ステータスコードが変わるようにします
Mockの場合、
“statusCode”に
設定します
メソッドレスポンスでステータスコードを定義する
ここに利用するステータスコードを列挙します
統合レスポンスでレスポンスをマッピングする
統合リクエストの”statusCode”と
メソッドレスポンスで定義したステータスコードをマッピングします
※メソッドレスポンスで
指定したステータスコー
ドしか選択できません
他にも。。。
• 動的なレスポンス変更
• 認証を設定してみる
などなど、工夫は色々できます
5.まとめ
ServerlessじゃなくてもAPIGatewayは便利
• Serverlessじゃなくても、メインシステムがクラウドじゃなくても使える
• オンプレ開発のAPIモックに
• APIGateway→オンプレのWebサービスも可能
• Serverlessにチャレンジする前に
• Serverlessで詰まるのは多分LambdaよりAPIGateway
• Swaggerにも慣れておきましょう

APIモック3分クッキング