前回 からだいぶ期間が空いてしまいましたが、Amazon APIGatewayのHTTP Proxyを使ってKintoneのREST APIを呼び出す続編です。
注意
kintone REST APIは同時アクセス数がドメインごとに10と制限されています。
ドメインへの同時アクセス
・APIによる同時アクセス数はドメインごとに10が上限です。
実システムで利用する場合は、API Gatewayのスロットリング設定やエラーのリトライなどを考慮する必要が有ります。
注意ここまで
今回のゴール
Kintoneからエラーが返されたらAPIGatewayもエラーとなるようにしたうえで、Methodをデプロイします。
Kintone REST APIのエラーについて
REST APIの共通仕様 によると、
HTTPステータスコードが「200」であれば正常終了、それ以外はエラー終了です。 エラー時には下記情報を含むJSONデータをレスポンスとして受け取ります。
だそうなので、APIGatewayのIntegration ResponseでKintoneからのHTTPステータスコードを判定します。
判定基準としては2xx以外はすべて400 BadRequestで返すことにしましょう。
APIGatewayの設定
Method Response
HTTP Statusとして400を定義します。
Integration Response
HTTP endpoint(今回はKintone)からのHTTP statusが2xx以外はMethod response statusが400になるように設定します。
Method をテスト
前回と同じようにBodyを空にしてテストを実行します。
期待通り、APIGatewayのResponseが400になりました!
デプロイとStage Variablesの設定
Methodを"prod"という名前のStageにデプロイしてから、Stage Variablesを編集します。(StageNameはなんでもいいです)
呼ぶ!
$ curl -X POST -H "Content-Type: application/json" -d '{"item1":"request from curl","日本語項目":"curlから送信"}' "https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prod"
結果(curl)
{"id":"16","revision":"1"}
結果(Kintone)
やりました! これでKintone隠蔽した状態でKintone REST APIを呼び出せるようになりました。
緊急ニュース
つい先日、CloudFormationがAPIGatewayをサポートするようになりました!
ここまでやったことが一気に作成できてしまいますので、次回はCloudFormation化とCORS対応を一気にやってしまいたいとおもいます。
では!