はじめに
このエントリは、初挑戦カレンダー Advent Calendar 2025 の 7日目記事です。
https://qiita.com/advent-calendar/2025/silvia
今年、Twitterで何か主張したかったことを拾いながら記事を書いていきます。
本文
APIには入力値が正しいかどうかを確認するためのバリデーションチェックが必要だ。
バリデーションチェックを行わないと、想定外のデータを受信した時に、システムが止まってしまったり、最悪の場合は情報流出が発生して大変な事になる可能性がある。
なので、APIはバリデーションチェックを必ず実装する。
そのバリデーションチェックだが、私はずっとバックエンドで行うのが当然だと考えていた。
何故なら、APIというものはどんな呼ばれ方をするか不明で、呼び出し元を信用すべきではないとずっと教わって来たからである。
まずはフロントエンドでバリデーションチェックを行い、バックエンドでももちろん行う。
これに疑問を持ったことは無かった。
しかし、TLで少し気になる主張を見かけ、もしかしたらそれが常識ではなくなってきている時期が来たのかもしれないと思うようになった。
TLで見かけたのは、受信するデータが信用できるのであれば、オーバーヘッドとなるバックエンドのバリデーションチェックは不要だという話だった。
そして、仮に受信したデータに異常があったとしても、DBのデータ設計で吸収し、DBエラーとして返すことでアプリを高パフォーマンスに設計できるという、確かに頷けるものであった。
APIというものは受信データを信用するべきではない。それは今でも間違いではないと思う。
多くのサブシステムがあり、システム間連携を行うようなAPIであればなおのこと。
しかし、サービスの設計によってはバリデーションチェックのサーバオーバーヘッドを取り除ける可能性があるという話は、それはそれで興味深いものだ。
ただ恐らくは、そのような設計が必要な場面は、レスポンス速度が要求され、かつデータ設計がシンプルに設計できるようなそこそこ限定された状況だろう。
クラウドサービスでのビッグデータ収集などがそれに該当するかもしれない。
基本的には、バックエンドのバリデーションチェックを実装すべきなのは、今後も変わらないだろう。
しかし、不要な設計もできるという選択肢を持っておくことは、今後何かの一助となるかもしれない。