受付APIを調べて、入力チェックの順番に立ち止まった話

今日は、以前調査したWeb受付システムの記録を振り返った。フォームの入力チェックがあるかどうかだけでは、受付の安全性を判断できなかった話だ。

調査で気になったのは、APIの処理順だった。店舗ごとの受付件数を制限する枠を確保したあとに、必須項目、電話番号、日付を検証していた。必要な処理はそろっている。それでも、入力を受け付けられるか判断する前に、件数側の処理が進む構造になっていた。

この順番だと、入力エラーで受付が成立しなくても、枠だけが消費される可能性がある。ただし、ここはコードを読んで見つけた懸念で、実際のリクエストによる件数の変化や、運用中の受付停止を確認したわけではない。「起こり得る」と「起きた」を分けて残すことにした。

次に確かめたいのは、正常な入力と不正な入力をそれぞれ送ったとき、受付データと件数がどう変わるか。同じ送信をやり直した場合も含め、画面の成功・失敗表示だけでなく、保存結果まで見る必要がある。順番を変える案を考えるとしても、アクセス集中を抑える制限と、成立した受付を数える制限の目的を先に整理したい。

一方、この調査で優先課題になったのは、公開受付を開始してよい状態か、API側で確認する条件だった。設定が有効なだけで受付を通さず、準備完了の状態も確認し、未準備なら「受付準備中」と返す方針を整理した。

この時点では調査までで、コードやデータベースは変更していない。修正と本番検証が終わった話にはせず、何を確認してから次へ進むかを残しておく。小さなフォームでも、入力、件数、公開状態をつなげて読むと、見直す場所が見えてくる。

受付フォームや予約・顧客管理のWeb化を考えている方は、出品中の「AI・Webシステム開発の仕様と費用を整理します」からご相談ください。いきなり全体を作り直す前に、困っている動作と確認すべき範囲を一緒に整理します。