エラーをHTTPクライアント/サーバー通信なしでHTTPエラーとして限定することは意味がありますか
REST ApiにC＃クライアントSDKを記述しています。このSDKはJSONシリアル化モデルをAPIに送信し、パラメーターの第1レベルの検証を実装します。検証が失敗した場合、例外。
例は次のとおりです。
if (requiredParameter == null)
{
throw new ApiException(400, "Missing required parameter");
}
ご覧のとおり、ApiExceptionは、HTTPエラーコードを表すパラメーターとして整数を受け取ります（そのコンテキストでは「Bad Request」）。 クライアントとサーバー間でHTTP交換が行われていないときにHTTPコードが意味的に使用されることを意味しているとは思えません（そのコンテキストでさらに進むと、400エラーコードが発生しますがサーバーからの返信）。
この件について少し考えてみたいと思います。
これは奇妙に思われるかもしれませんが、RESTfulnessについて誰もが考える今日、私は驚くことはできないと思います
クライアントは、偽の公開ではなく、基礎となる実装を非表示にすることを期待します。
したがって、パラメーターが欠落している場合は、標準のArgumentExceptionをスローするか、送信前に呼び出す必要があるカスタム検証メソッドをいくつか用意してください。
サーバーがHTTP応答コードを返した場合は、それをインターセプトして解析し、それがRESTfulな応答の一部である場合は適切なエラーに変換されます。
HTTP通信での正当なエラーである場合にのみ、HTTPエラーコードでHttpExceptionがスローされることを期待します。