【要約】Amazon API Gatewayで "+" が消える!? クエリ文字列のデコード挙動を検証してみた [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
システム間のAPI連携において、送信したクエリ文字列の値が意図せず書き換わる問題が発生した。開発者がシステムAからシステムBへリクエストを送る際、Lambda側で必須項目が正しく受け取れない事象に直面した。具体的には以下の課題が挙げられる。
- ・Amazon API Gatewayがクエリ文字列をデコードする際、記号を書き換えてしまう。
- ・「+」記号が、application/x-www-form-urlencodedの仕様に基づき半角スペースとして解釈される。
- ・電話番号やBase64文字列など、記号を含むデータが破損し、後続の処理でエラーを引き起こす。
// Approach
開発者は、API GatewayとLambdaを用いた最小構成の検証環境を構築し、リクエスト形式による挙動の違いを比較した。実際のネットワーク経由のリクエストを再現するため、curlコマンドを用いた検証手法を採用している。
- ・検証環境の構築：API GatewayとLambdaを組み合わせ、受信したイベント内容をそのまま返す構成を作成した。
- ・比較パターンの設定：未エンコードの「+81」と、パーセントエンコード済みの「%2B81」の2パターンを用意した。
- ・検証ツールの選定：コンソールのテスト機能ではなく、実際のHTTPリクエストを模したcurlコマンドを使用し、正確な挙動を確認した。
// Result
検証の結果、未エンコードの「+」は半角スペースに変換されるが、正しくエンコードされていれば正常に受信できることが判明した。
- ・パターン①（未エンコード）：
tel=+81はtel: " 81"となり、データが破損した。 - ・パターン②（エンコード済）：
tel=%2B81はtel: "+81"となり、期待通りに動作した。 - ・検証の注意点：API Gatewayコンソールの「テスト」ボタンは、内部API経由の疑似実行であるため、実際のデコード挙動を再現できないことが明らかになった。
Senior Engineer Insight
> 本件は、プロトコル仕様の解釈違いに起因する典型的な「隠れた仕様」である。特に、API Gatewayコンソールのテスト機能が実際の挙動を反映しない点は、デバッグ時の誤判断を招く重大なリスクとなる。設計段階において、記号を含むデータはクエリ文字列ではなく、JSON形式のリクエストボディに含めるべきである。これにより、デコード仕様に依存しない堅牢なインターフェースを構築できる。実戦では、こうした「仕様の隙間」を意識した設計が、運用コストの低減に直結する。