バックエンドAPIのエラー応答方針を決定し、ドキュメントとサンプルアプリケーションに反映する

[kharada7]

概要

現状、例外発生時のエラー応答方針が以下の点において定まっていない。

POST / PUT / DELETE / PATCH でキーに対応するリソースが見当たらない場合

• 案1： 404 を返す（ API Controller で明示的に返す）
• 案2： 400 を返す（ ExceptionFilter に処理を任せる）

決めの問題だが、どちらを採用するにせよサンプルの実装は方針に合わせる必要がある。

完了条件

• 更新系 Web メソッドでキーに対応するリソースが見当たらない場合の方針が決まっている
• サンプルに反映されている
• ドキュメントに反映されている

[KentaHizume]

409 Conflictについて

409 を返却しない場合

フロント側でステータスコードに合わせた処理を行う要件がない場合は、400にまとめてしまうことも考えられる。

409を返却する場合

Controllerで都度DbUpdateConcurrencyExceptionをcatchするのではなく、
BusinessExceptionFilterと同様にFilterを作成してDbUpdateConcurrencyExceptionを409レスポンスに変換するような仕組みにしたほうがよい。

レスポンスボディについて

BusinessExceptionFilterでは、業務例外が発生した場合はValidationProblemDetailsを返却しているが、
DbUpdateConcurrencyExceptionはモデルの検証エラーではないので、ProblemDetailsをそのまま使用したほうがよい？

https://learn.microsoft.com/ja-jp/dotnet/api/microsoft.aspnetcore.mvc.problemdetails?view=aspnetcore-8.0

[KentaHizume]

RFC7807 (Problem Details for HTTP APIs)

メンバーはtype、title、status、detail、instanceの5つで、
type以外は必須ではなく、メンバーを拡張してもよいので自由度が高い。

https://datatracker.ietf.org/doc/html/rfc7807
typeがない場合はabout:blankとして解釈し、typeも必須ではないらしい。
https://learn.microsoft.com/ja-jp/dotnet/api/microsoft.aspnetcore.mvc.problemdetails.type?view=aspnetcore-8.0#microsoft-aspnetcore-mvc-problemdetails-type

  Consumers MUST use the "type" string as the primary identifier for
   the problem type;

   {
    "type": "https://example.com/probs/out-of-credit",
    "title": "You do not have enough credit.",
    "detail": "Your current balance is 30, but that costs 50.",
    "instance": "/account/12345/msgs/abc",
    "balance": 30,
    "accounts": ["/account/12345",
                 "/account/67890"]
   }

   {
   "type": "https://example.net/validation-error",
   "title": "Your request parameters didn't validate.",
   "invalid-params": [ {
                         "name": "age",
                         "reason": "must be a positive integer"
                       },
                       {
                         "name": "color",
                         "reason": "must be 'green', 'red' or 'blue'"}
                     ]
   }

[KentaHizume]

maiaの下記のissueでProblemDetailsのメンバーの拡張が検討されているので、対応されたら内容をmarisにも取り込む必要がある。

• アプリケーションアーキテクチャ概要編にメッセージ管理方針を追記する maia#89 (comment)