validation - HTTP 409 を返すことは検証チェックに適していますか?

Question

特定の操作を実行する前に、いくつかの検証ルールをチェックする必要があるサービスがあります。

たとえば、すべての検証ルールが満たされていない場合、クライアントは印刷可能なレポートを生成すべきではありません。

ただし、個々のクライアントが必要なすべての情報を持っているとは限らないため (そのユーザーは、検証の成功を判断するために使用されるデータのサブセットにしかアクセスできない場合があります)、要求をサーバーに送信する必要があります。thingとstart" finish.

VALID: FEEL FREE TO CONTINUE応答は、ユーザーに提示できる、を示すある種のトークン、または検証失敗の理由のリストのいずれかになります。

検証が成功すると . が返されることは明らかです200 OK。しかし、成功ステータス コードが検証の失敗に適しているとは思いません。私は a に傾いてい409 Conflictますが、これを使用して aPUTまたはを拒否しただけPOSTです。で示される検証の失敗を持つことは有効ですか (スニッカー) 409、またはより良い方法はありますか?

注: 実行されたアクションはサーバー上で実行されていないため、このチェックをスキップしてアクションを試行するだけ403で、アクションが禁止されている場合はオプションではありません。

Answer 1

検証を実行するためにサーバーにリクエストを送信しました。上記の検証を正常に実行しました。HTTP の観点からは、要求は整形式であり、サーバーによって正しく処理されました。

したがって、HTTP エラー コードを返すのは正しくないと思います。

---

この回答には引き続き反対票が寄せられており、その理由は完全にはわかりません（反対票を投じた人は誰もコメントを残していないようです）。OP とかなりの量のやり取りを行った結果、この要求/応答の要点は検証を実行することであることがわかりました。サーバーは要求を受信し、実行するように要求された検証を実行し、その検証プロセスの結果を呼び出し元に返しました。

このリクエストを送信したクライアントには、何の問題もありませんでした。

サーバーは要求を理解しました。

リクエストは有効でした (HTTP の観点から)。

サーバーはリクエストを処理できました。

サーバーは意図されたアクティビティの 100% を実行し、要求を処理して生成された結果を返しています。

そのため、私が言うように、HTTP エラー コードが適切であるとは思えません。

つまり、サーバーが電子メールアドレスを検証するエンドポイントを公開していると想像してください (検証を実行できると言いたい特定のフォームに対して)。「abc@invalid.org を検証してください」という要求を受け取り、「このメール アドレスを確認しましたが、無効なアドレスに対して有効な DNS 応答を取得できないことをユーザーに伝えてください」という応答を生成します。 .org". ここで 200 の回答が正しいと思わない人がいる場合は、その理由を理解したいと思います。

Answer 2

提案された標準ではまだ定義されてい422 Unprocessable Entityますが、適切なステータスです。

422 (Unprocessable Entity) ステータス コードは、サーバーがリクエスト エンティティのコンテンツ タイプを理解していることを意味し (したがって、415 (Unsupported Media Type) ステータス コードは不適切です)、リクエスト エンティティの構文は正しい (したがって 400 (Bad Request) ) ステータス コードが不適切です) が、含まれている命令を処理できませんでした。

たとえば、このエラー状態は、XML 要求本文に整形式 (つまり、構文的に正しい) が含まれているが、意味的に誤った XML 命令が含まれている場合に発生する可能性があります。

参考文献:

• https://www.rfc-editor.org/rfc/rfc4918#section-11.2
• http://developer.github.com/v3/#client-errors
• https://stackoverflow.com/a/2657624/247702
• http://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_Error

Answer 3

よくあることですが、自分が何を、どのように、なぜ行っているのかを正確に把握していないと、正確にアドバイスすることは困難です。たとえば、次のようになります。

特定の操作を実行する前に、いくつかの検証ルールをチェックする必要があるサービスがあります。

このサービスはローカル コードを提供していますか? その場合は、ローカル コードに例外をスローするか、通常のものを返す必要があります。
APIリクエストに関連付けられていますか? もしそうなら、1 つのリクエストですべてを行うのではなく、別の REST 呼び出しで検証する理由がわかりません。

ただし、個々のクライアントが必要なすべての情報を持っているとは限らないため (そのユーザーは、検証の成功を判断するために使用されるデータのサブセットにしかアクセスできない場合があります)、要求をサーバーに送信する必要があります。開始から終了まで有効なもの」。

例として仮定を立てていますが、たとえば、必要なデータなどがすべて揃っている場合に要求を行い、その時点で検証することができます。

応答は、VALID: FEEL FREE TO CONTINUE を示すある種のトークン、またはユーザーに提示できる検証失敗理由のリストのいずれかになります。

上記の要件は次のように読み取れるため、これが私が持っているものを提案している理由です。

1. リクエストを API に送信すると、API は検証を実行してレスポンスを返します。
2. 応答が有効である場合、ユーザーは次の応答を送信して実際の処理を行います。
3. 応答が無効であると表示された場合、ユーザーは何らかの操作を行い、有効な応答が得られるまで再試行する必要があります。その後、実際の操作を行う必要があります。

別：

1. リクエストを API に送信し、検証を実行します。有効な場合は処理を行い、そうでない場合は無効な状態を示す応答を返します。
2. ユーザーが変更を行い、検証と実際の処理を行うために送信する要求が 1 つだけあります。

注: 実行されたアクションはサーバー上で実行されていないため、このチェックをスキップしてアクションを試行するだけで、アクションが禁止されている場合に 403 を返すことはできません。

これがリモート/API リクエストの種類ではない場合は、HTTP コードを使用しないことをお勧めします。これはすべて同じコードベース内で行われているのでしょうか? その場合、ユーザーにメッセージを提供するための検証からの例外またはブールなど。

Answer 4

コードを意図しないものに誤用しない限り、それは本当に好みと意見に帰着すると思います。409はおそらく検証の失敗に使用しても大丈夫ですが、私は個人的には検証エラーを応答として持つ200を好むと思います。これにより、開発者は、送信したデータの検証について心配する前に、401や500などの一般的な通信エラーをチェックして対処することが容易になると思います。