バリデーションエラー サーバサイドレンダリング時のHTTPステータスコードについて

バリデーションエラーについてAPIは400を返す　ですんなり納得いったが、APIとしてではなく、SSR（サーバサイドレンダリング）するようなケースも400を返すのか？200のほうがよい？について少し気になったでメモ。

結論

個人的には以下に落ち着いた。
200と400どちらがよいかは、プロジェクト・チームで方針を合わせておけばよいと思う。

詳細

API

いくつか記事をみたところ400に着地していてこれは納得できる。
https://qiita.com/nesheep5/items/6da796f6ac628c430c36

SSR

これについての記事はみつけられなかった。

• SSRの場合に200を返してもよいのではと思った理由
  • SSRの場合、バリデーションエラーになったとしても、画面をレンダリングするということが責務だとすると、エラーメッセージとともに画面を再表示するという風に解釈すると200を返すことでも納得できる。
  • いくつかのフレームワークの実装などをみるとSSR時はそのまま200を返している(というより、テンプレートを指定しているだけで、httpStatusCodeをわざわざ設定していないからそのまま200になっている）がみられた。
  • spring bootだとbindingResultでvalidation結果を取得してそれをviewに返す例も多い(この場合も200を返す）

sample.java

    @PostMapping("/register")
    public String registerUser(@Validated @ModelAttribute("userForm") UserForm userForm, BindingResult bindingResult, Model model) {
        if (bindingResult.hasErrors()) {
            return "register"; //registerというviewを返す HTTPステータスコードは200
        }

• その他、近いような議論をしていた記事
  • https://stackoverflow.com/questions/3290182/which-status-code-should-i-use-for-failed-validations-or-invalid-duplicates

200
Ugh... (309, 400, 403, 409, 415, 422)... a lot of answers trying to >guess, argue and standardize what is the best return code for a >successful HTTP request but a failed REST call.

の箇所。ここではHTTPとRESTfulを混同しないように的なことで議論されていて近いものはあるかなと思った。記事を追ったが、そういう考え方もあるというのでどっちが正解というのはなさそうだった。

• SSR時でも400を返しておいた方が良いと判断するポイント
  • テストがやりやすい
    • ステータスコードが200だとバリデーションできたかはhtmlをみないといけない。400にしておけば楽。
  • 同じリポジトリ内にSSRとAPI呼び出しが混ざっている
    • APIはバリデーションエラー400で返しているのにSSRの箇所は200なの気持ち悪いという議論になりそうなのでこういう場合はもう400にしてしまったほうがよいのかなと思う。