門番を置いて、平和なバックエンドを守ろう。APIゲートウェイでの「リクエストバリデーション」入門
こんにちは！ネットワークとプロトコルの深淵を愛するインフラエンジニアです。
皆さんは、Web APIを作るとき、こんな経験はありませんか？
「バックエンドのコードで、送られてきたデータが正しい形式かどうかを一つ一つチェックしていて、なんだかコードが汚くなってしまう…」
「不正なデータが飛んできて、データベースがエラーを吐いてログが真っ赤になる…」
これ、実はAPI開発の「あるある」なんです。今日は、そんな悩みをスッキリ解決する「APIゲートウェイでのリクエストバリデーション」という、いわば「最強の門番」を設置する方法についてお話しします。
—
APIゲートウェイは「優秀な受付係」
まず、想像してみてください。あなたは巨大なマンション（バックエンドサーバー）の管理人です。
もし、住民（サーバー内のプログラム）の部屋に、誰彼構わず怪しい訪問者が突撃してきたらどうなるでしょう？住民は対応に追われて本来の仕事ができなくなってしまいますよね。
APIの世界でも同じです。バックエンドのサーバーに無駄なチェックをさせず、快適に働いてもらうためには、マンションの入り口（APIゲートウェイ）で「ちゃんとした訪問者かどうか」を判断する受付係を置くのが正解なんです。
これが「APIゲートウェイでのリクエストバリデーション」です。
—
なぜ「OpenAPI」を使うのか？
バリデーションをするためには、「何が正解で、何が間違いか」というルールブックが必要です。そこで登場するのが OpenAPI Specification です。
OpenAPI とは、APIの「設計図」です。「このAPIには数字の id が必要で、名前には name という項目を文字列で送ってね」というルールをYAML形式で記述します。
この設計図をAPIゲートウェイに渡すと、ゲートウェイは「おっ、このリクエストは設計図通りじゃないな。中に入れるわけにはいかないぞ！」と、門前払いしてくれるようになるのです。
—
実践！ルールブック（OpenAPI）を書いてみよう
例えば、ユーザー登録のためのAPIを想定してみましょう。名前（name）は必須、年齢（age）は数字、というルールを定義してみます。
# OpenAPIの定義例
paths:
/users:
post:
summary: ユーザー登録API
requestBody:
required: true
content:
application/json:
schema:
type: object
properties:
name:
type: string # 文字列であること
age:
type: integer # 整数であること
required:
- name # nameは必須！この定義をAPIゲートウェイ（AWS API GatewayやKongなど）に読み込ませるだけで、ゲートウェイは自動的に「name がないリクエスト」や「age に文字列が入っているリクエスト」を、バックエンドに到達する前に遮断してくれます。
—
門番がいるメリット：3つの「嬉しい」
この仕組みを導入すると、現場ではこんなに良いことがあります。
1. バックエンドが楽になる：
「型が合っているか」「必須項目はあるか」といった退屈なチェックコードを、バックエンドに書く必要がなくなります。本質的なビジネスロジックに集中できるんです。
2. 不正リクエストによる障害を防げる：
例えば、「巨大なデータを送りつけてサーバーをダウンさせようとする攻撃」なども、サイズ制限をルールに入れておけば、ゲートウェイで簡単に防げます。
3. 仕様と実装のズレがなくなる：
設計図（OpenAPI）がそのまま門番のルールになるので、「設計ドキュメントと実際のプログラムが違う！」という悲しい事故が起こらなくなります。
—
インフラエンジニアからのアドバイス
「バリデーションはバックエンドでやるのが当たり前」と考えているエンジニアも多いかもしれません。しかし、ネットワークの知見から言わせてもらえば、「できるだけ入り口に近い場所で拒否する」のが、システム全体の負荷を下げる鉄則です。
パケットがネットワークを旅して、あなたのサーバーに届くまでの距離を短縮する。そして、無駄なパケットを処理させない。これこそが、堅牢で美しいAPI設計への第一歩です。
まずは今あるAPIの設計図を OpenAPI で書き起こすところから始めてみませんか？あなたのサーバーが、きっともっと身軽に、そして安全に動くようになるはずです。
もし「設定方法で詰まった！」ということがあれば、いつでも相談してくださいね。ネットワークの深淵でお待ちしています！
コメント