月別アーカイブ: 2021年10月

API Gateway を用いたHTTPメソッド呼び出し

AWSのAPI Gatewayを触っていて、若干混乱してきたので、簡単ではあるけれどまとめる

API Gateway が対応しているAPIのタイプとしては下記の4種類
  ・HTTP API
  ・WebScoket API
  ・REST API
  ・REST API (プライベート)

GCPで提供しているAPI GatewayプロダクトであるApigeeでは、WebScoketに対しての対応が正直いまいちなので、そういう意味ではWebScoketを試してみたいが、WebScoketクライアント用意したりするのも面倒なので、ここでは通常のREST APIを題材とする

まずは、APIの集合体に対しての名前付けとプロトコルの選択をする。
REST APIを選択したはずなのに、WebScoketが選択肢として残っているのは意味があるのだろうかと疑問を感じるが、気にしない。
ちなみにエンドポイントタイプのデフォルトは”リージョン”。エッジ最適化を選択すると、CloudFrontが用いられる形のグローバル利用を想定したAPIになる。

ここでは、GithubAPIを例にして作ってみることにする

初期状態ではAPIのRootが存在するだけ。ここからリソースやメソッドを追加していく。まずはGistのAPIを作ってみようと思うので、リソースの追加でGist。メソッドとしてGetを追加してみる。

GETメソッドを追加すると上記のセットアップ画面に。
「統合タイプ」という日本語がどうなのか?という気がするが、呼び出しとして何を利用するのかを選択することができる。
多くのAPI GatewayチュートリアルではLambdaを呼び出すつくりになっている。
既存のAPIをEC2や別途提供しており、それを呼び出す形であればHTTPになる。

試しに、GithubAPIを直接呼び出してみる
  ・統合タイプを「HTTP」
  ・HTTPメソッドを「GET」
  ・エンドポイントURLを「https://api.github.com/gists」
にする

メソッドを作成するとこのような画面になる

ブロックが大きく分けて4つ。

メソッドリクエストクライアントから見た時のこのAPIの呼び出し仕様の定義
統合リクエスト統合先(最終的な呼び先、ターゲット)をどう呼ぶのか
統合レスポンス統合先からのレスポンスをどう処理するかを定義。
基本的にはそのままだと思う
メソッドレスポンスクライアントに返すレスポンスの定義

“テスト”をクリックし、実際にメソッドを走らせてみると、レスポンスとしてGithub.comから結果を受け取れていることが確認できる。

これでメソッドとしては作ることができたのだが、本家のAPIではいくつかのQueryParameterを受け取ることができる。せっかくなのでこれも実装する

「メソッドリクエスト」にて「URLクエリ文字列パラメータ」を追加する。本来はどれも任意のパラメータだが、試しにpageとper_pageを必須にしてみる

見ると、統合リクエスト側にも自動的に追加されていた

クエリパラメータを指定せずにテストをしてみると、エラーに・・・ならない。
よく見ると、メソッドリクエストに黄色△マークが出ている。

結論からいうと、デフォルトでは値の検証機能はなぜかOFFになっていて、明示的に指定する必要があった。
「設定」欄にある「リクエストの検証」を選択する

それにしても、UIが鉛筆マークがついているとはいえ、何が設定値なのかの判別が難しすぎる。非常にわかりづらいと思うのは私だけであろうか。

これで実行すると、期待通り400エラーとなってくれ、パラメータを指定することで結果が正しい形で取得出来ていることが確認できる。

次にsinceパラメータを試してみる。
ちょっと意地悪で、日付書式不足を設定してみると

書式のバリデータに引っかかったようで、レスポンス本文にエラーが出ている。
ただ、ステータスコードは200となってしまっている。
ログを見ているとわかるのだが、実際のところGithubからは422が返却されている。

これは、API Gatewayの設定で「メソッドレスポンス」と「統合レスポンス」を正しく設定していないことに起因する。
デフォルトでは、すべてのレスポンスがステータスコード200で返却するようになっているのだ。

とりあえず、ありえそうなメソッドレスポンスを定義して

統合から何が返ってきたときにどのメソッドレスポンスを関連付けるかを設定します

そもそも、デフォルトが200というのがおかしいのであって、統合から200が返ってきたときだけ200を返却し、定義にない返却値の場合は500にしておいた。
デフォルトのマッピングは、項目でいうと「HTTPステータスの正規表現」を空にするとよい

これで、クエリパラメータの書式エラーは500となった。

未定義のステータスコードがデフォルトになってしまうというのはどうなんだろう?
そのまま返してくれればいいのになってことで、デフォルトをなくしてみると

結局500エラーで、しかもInternal Server Errorときたものだ。

ままならぬ。
本当はバージョン管理周りをまとめたかったのだが、そこまで行きつかなかったので次回に。。

思い込みレベルキャップ

ふとした思い付きで、就職時に同期だった友人に15年ぶりくらいに連絡を取った。

彼が転職するまでは、それなりに家が近かったこともありたまにご飯を食べたりもしたものだが、私も忙しくなり、彼も転職してしまったりで疎遠になってしまっていた。
Facebook等では時々フレンド候補には出てきていたのだが、今さら感が満載で申請等もせず、ずっと放置状態だったのを思い立ったのが今回というわけです。
深い意味はなかった。

そんなこんなで十年以上ぶりに連絡を取ったのだが、彼もマラソンをここ数年取り組んでいるようで、投稿を見てみるとものすごい早い。

すごい

日ごろの走り込みもしっかりしているし、月間の走行距離も、私が160kmを目標にしているのに対して普通に250kmくらい走っているように見受けられる。

いやはや、すごい

ただ走るだけではなく、インターバル走などのしっかりとしたトレーニングのようなものも行っているようで、ちょっとのめりこみすぎではないかと思うくらいだ。

色々と驚くことばかりだが、ちょっともっと自分もがんばらないといけないのではないか?と思えてきて週末は頑張って走った

だいたいハーフマラソンくらいの距離をギリギリ5分を切るくらいのペース。

数か月前にこれくらいの距離を走った際は、途中で休憩やらなんやらを入れて走った記憶があり、今回は信号以外ではあまり止まらずに走った(少し止まったところはある。。)

もちろん、これは走り続けていることで、これくらいの距離は大丈夫になってきたという見方もあるが、実際のところ1週前は10km走るのにも疲れて歩くこともあったわけ。
そう考えると、比較的知っている人が出来ているのを見ることで、自分ももっと出来るのでは?という気持ちの変化によるものではないのだろうか?と思えてもくる。

似たようなことは昔もあって、出来ないだろうと思っていることを周りでやっているのを見ると、「あぁ、それ出来るんだ」って思えて自分でやってみるとできるという状態。

人に引っ張られるということでもあるけれど、見方を変えると勝手に自分でレベルキャップをつけてしまっているということなのかもしれない。

ちょっとカッコ悪い話でもあるけれど、若干いまだに自分はそうなんだなぁと再認識してしまった感はある。

でも、逆に言えばまだまだ成長の余地があるということではないだろうか。
ということにして、いい歳しても、まだまだいけると頑張っていきますよ

SAA取得!

以前、書いたように AWS 認定資格である Solution Architect Associate 試験を昨日受けてきて、無事に合格しました

SAAは問題の難易度というか深さでいえば、それほど深くはないんでしょうけれど、出題範囲がとても広いので覚えるのが大変。
出題範囲の中心は主要サービスとはいえ、実際に自分で使ったことがないサービスが多いので、様々なケースにおいて何を選択すればよいのか?ということに関しては、合格した今でも不安が残ります。
だからこそAssociateレベルなんでしょうけれど。

実際のところ、これを取得したところでAWSに関して詳しくなったという実感はなく、こういうケースはどうなんだろう?という問いに、実際に実施できるのか?に関しては難しい。
いわゆる、「全然わからん」という状態になっている気分です。

というわけで、やはり次は開発だろうということで、Udemyにてコースを購入。勉強し始めました

Ultimate AWS Certified Developer Associate
https://www.udemy.com/course/aws-certified-developer-associate-dva-c01/

ちゃんと使えるように、SAAで勉強した内容をもとに実際に触って学んでいきたいところ。

いやはや、学びは尽きないですね。
自分のレベルが低いことはわかってはいるものの、少しずつでもマシになれるように頑張るぞっと

追記
よくよく見てみたら、スコアを発見。
720点合格で787点ということで、結構ギリギリだった。。。危ない危ない