概要
Web界隈でよく聞くバリデーションについて本当に概要部分を簡単にまとめます。
※本記事に具体的なコードは出てきません。各々お使いのフレームワークなどのドキュメントでバリデーションの実装方法をご確認ください。
バリデーションって？
バリデーションとは簡単に言うと「イケてないデータをフィルタリングするもの」であると思っていただいて大丈夫です。
ちょっと難しい言葉でいうと「特定の条件・規則を満たしていることを確認するプロセス」です。
※スペル的に「ヴァリデーション」が正しいようだが、本記事ではあえて馴染みのある「バリデーション」を用います。
バリデーションがなかったら？
もしバリデーションを設定していなかったら「イケてないデータ」が皆さんの作るシステムに入ってきます。これによって処理がうまく動かなかったり、データが保存できなかったり、意図しないバグが発生する場合があります。
例えばユーザー登録時に、ユーザー名は必ず入力してほしいのにユーザーさんが入力を忘れて「登録」ボタンをクリックしてしまったとします。システムは「ユーザー名は必ず入っていること前提」で作成されている場合「必ずあるはずのものがない状態」になり、十中八九エラーで処理が停止します。
対応策としては主に下記が上げられます。
- ユーザーさんにユーザー名を絶対入力してもらえるようにしてもらう。
- ユーザー名がない状態を感知して、ユーザーさんにその旨を伝えて入力してもらう。
前者で我々開発者ができることとすれば入力欄付近に「ユーザー名は絶対入力してください！」と文言を表示するくらいです。ただし、人間は忘れる生き物です。注意喚起されていても忘れてしまったり、そもそもいたずらであえて入力しない人もいるかも知れません。その都度「エラーが発生しました。最初からやり直してください」というような画面が出ていたらユーザー体験はよくありません。
なので後者でカバーします。これがバリデーションです。「イケてないデータ」だった場合にユーザーさんにそれを伝えて正しい情報で再度送ってもらうというのがバリデーションです。
じゃあバリデーションはどこで使うの？
まずは下記の画像をご覧ください。画面で入力された処理がどのように移動して永続化（DBに保存）されるかを簡略図で表しました。（フロントとバックが分かれていますが、フロント・バックが分かれているAPIベースのシステムに限った話ではないです。説明の便宜上このような書き方をしています。）
矢印はデータの流れだと思ってください。
それぞれ例を見てみましょう
星1
これは先程の図だと少し星の位置が不適切かもしれません。
実際には「ユーザーが情報を入力中に動的にチェックする」バリデーションについて伝えたかったです。
ユーザーフレンドリーなページでパスワードの登録時の入力中に「パスワードが短すぎます」や「大文字を含んでください」などの内容が表示されるものです。
「保存ボタン」を押さずとも、入力内容に応じて入力内容をチェックして「イケてないデータ」ならエラー内容を表示するものになります。
星2
これは画面上で入力が終わり「登録ボタン」をクリックしたあとに入力されたデータが「イケてないデータ」かどうかをチェックします。
「やっと登録できた〜登録ボタンポッチっとな」としたときに「何だよ、条件に合ってなくてパスワードサイド入力しないとじゃん、めんどくさいなあ」となるやつです。
データを処理（バックにわたす）前にチェックするイメージです。
星3
実は星2と星3はユーザーから見分けがつかない事がほとんどです。（一部のマニアックなお友達ならブラウザの検証モードですぐわかるのですが）
星3でも下記と同じことが起こります。
「やっと登録できた〜登録ボタンポッチっとな」としたときに「何だよ、条件に合ってなくてパスワードサイド入力しないとじゃん、めんどくさいなあ」となるやつです。
それでは何が違うかというと、チェックしている場所が違います。
星2では画面（フロント）でデータをチェックしていました。
星3では処理（バック）するところでデータをチェックします。
属にいう「APIのバリデーション」はこの星3に該当します。
「イケてないデータを処理の直前で発見する」「イケてない内容をフロントに返して、イケてるデータを送り直してもらう」という感じです。
星4
これは永続化（DB）直前でチェックする方法です。
永続化（DB）する場所のルールにデータが適合しているかをチェックします。
ユーザーさんの入力起因というよりは処理（バック）を抜けてきたデータが意図しない形になっていないかをチェックする意味合いが強いです。
よっぽどのことが無い場合、このエラーの内容をユーザーさんが詳細に知ることはありません。
セオリー（所感）
基本的に星2と星3のバリデーションを併用する方法が一般的です。（一部フレームワークで表示テンプレートまで受け持つ場合はは星3のみの場合もあり）
イメージとしては、「フロントからデータが出るときに「イケてるデータ」かをチェックする + バックで処理が始まる直前で「イケてるデータ」かをチェックする」
です。
よりユーザーフレンドリーにするならこれに星1を追加、要件として永続化時にエラーを発生させたくないなら星4をプラスするイメージです。
外部サービス（API）を使うとき〜上級者向け〜
外部サービスや外部APIを使う場合、処理や永続化部分は我々がどうこうできる範囲ではない場合があります。
その場合、星1や星2で我々は対応する必要があります。
また基本的に外部サービスは外部APIは星3の実装が行われています。
外部サービスや外部APIのドキュメントを確認し、星3がどのような形式でエラーを返すのかを確認し、そのエラーが返ってきた場合、画面ではどのようなふるまいをするのかを決めて、実装する必要があります。