2

一部のフォーム POST リクエストが 4xx HTTP エラー (たとえば、間違った URL、期待されるフィールドの欠如、認証 Cookie の送信の失敗など) を引き起こすことは明らかですが、このような既存の質問は、すべての無効なフォーム送信を 4xx HTTP と見なす必要があることを示唆しているようです。エラー。本当に？

パスワードを誤って入力したり、必須フィールドを誤って省略したりすることは非常に一般的であり、アプリケーションで発生することが予想されます。これらが「HTTPクライアントエラー」を構成するべきであること、またはPOSTが永続的な状態変更をもたらす場合にのみ2xx成功と見なされることは、どの仕様からも明らかではないようです。

私の直感では、サーバーがクライアントにフォームを送信し、クライアントが期待されるすべてのフィールドを含む正しい形式の POST 要求でそのフォームに即座に応答する場合、一般的なビジネス ロジック違反は HTTP エラーではないはずです。

フォームが JSON-RPC などを介して送信される場合、状況はさらに明確ではありません。HTTP は単なるトランスポート メカニズムであり、関数が正常に呼び出されて応答が呼び出し元に返された場合、HTTP エラーは発生しません。

ごくまれに、一部のフォームが複数のことを実行し、一部が成功し、他の部分が失敗する場合があります。

理想的には、IETF は RFC でこれを解決し、「フォームの無効化の失敗により操作が実行されませんでした」という HTTP エラー コードを追加するか、これをカバーするために422の定義を拡張します。

4

1 に答える 1

1

ここに正解も不正解もありません。HTMLフォームは、HTTPの設計にある程度対抗していると思います。

ここでのブラウザは HTTP クライアントです。リクエストを送信して HTTP エラーを受け取った場合、レスポンスの本文をエコーし​​ますが、レスポンス コードはほとんど処理しません。

HTTP の観点からは、おそらくブラウザーはエラーを「更新」するべきではありません。おそらく、ユーザーにエラーを伝え、フォームを変更してリクエストを再試行できるようにする必要があります。

HTML の観点からは、エラーをまったく返さずに、通常は一連のクエリ パラメータを使用してフォームの URL にリダイレクトするのが最も賢明な方法です。

JSON-RPC の場合 (および XML-RPC、Soap などの多くのプロトコルだけでなく、GraphQL などの新しいプロトコルも)、HTTP とうまく調和する方法で HTTP を使用することはまったくありません。

その意味では、それらは HTTP アプリケーションではなく、HTTP を「トンネル」としてほとんど使用しています。彼らはHTTPをトランスポートとして使用しますが、「HTTPプロトコルを活用」しません。

このような状況では、http でエラー コードを発行するのは適切ではないと思います。エラーはより高いレベルで処理されます。おそらく、常に POST を使用して、応答本文でエラー情報を通信するときに 200 を返したいと思うでしょう。

質問に戻ります。

  • はい、HTTP の観点からすると、無効なフォームの送信は 4xx エラーになるはずです。無効なパスワード a 401。
  • いいえ、これは、HTTP を単にトランスポートとして使用するブラウザーやプロトコルなど、実際のすべてのユースケースで最も健全なことではありません。
  • しかし、REST ベースのアーキテクチャーを開発している場合、または意図したとおりに HTTP を使用したい場合は、これを行う必要があります。

422 に遭遇したとき、ブラウザは異なる動作をするべきですか? 多分。しかし、通常、「エラーが発生しました」というだけでは、優れた UX には十分ではありません。ブラウザが 422 でどのように動作するかを変更する以外に、ブラウザが問題をクライアントに返す方法に関するより具体的な情報を含むメディアタイプが必要になる場合があります。

于 2016-05-20T21:15:28.827 に答える