RESTfulログイン失敗：401またはカスタム応答を返す

これは概念的な質問です。

RESTful Webサービスに対するログインアクションをサポートする必要があるクライアント（モバイル）アプリケーションがあります。WebサービスはRESTfulであるため、これはクライアントがユーザーからユーザー名/パスワードを受け入れ、そのユーザー名/パスワードをサービスで検証し、その後のすべての要求でそのユーザー名/パスワードを送信することを覚えていることになります。

このWebサービスの他のすべての応答は、JSON形式で提供されます。

問題は、特定のユーザー名/パスワードが有効かどうかを単に確認するためにWebサービスにクエリを実行する場合、Webサービスが常にJSONデータで応答して成功または失敗を通知するか、または適切な資格情報とHTTPでHTTP 200を返すかです。資格情報が不適切な場合は401。

私が尋ねる理由は、他の一部のRESTfulサービスは、資格情報が有効かどうかを尋ねているだけの場合でも、不正な資格情報に401を使用するためです。ただし、401応答についての私の理解は、それらは有効な資格情報なしではアクセスできないはずのリソースを表すということです。ただし、ログインリソースの目的はすべて、資格情報が有効かどうかを通知することなので、ログインリソースはだれでもアクセスできる必要があります（SHOULD）。

別の言い方をすれば、次のようなリクエストのようです。

myservice.com/this/is/a/user/action 

不正な認証情報が提供された場合は401を返します。しかし、次のようなリクエスト：

myservice.com/are/these/credentials/valid

その特定のURL（要求）は有効な資格情報の有無にかかわらず許可されるため、401を返すことはありません。

これについて、正当化された意見がいくつかあります。これを処理する標準的な方法は何ですか？これを論理的に適切に処理する標準的な方法は何ですか？

最初に。401は、ログインに失敗したときに送信する適切な応答コードです。

401 Unauthorized 403 Forbiddenに似ていますが、特に認証が必要で失敗したか、まだ提供されていない場合に使用します。応答には、要求されたリソースに適用可能なチャレンジを含むWWW-Authenticateヘッダーフィールドが含まれている必要があります。

あなたmyservice.com/are/these/credentials/validがチェックするだけで401を送り返すという混乱は、RESTでのブールリクエストの実行がRESTfulな制約によってしばしば間違っているという事実に基づいていると思います。すべてのリクエストはリソースを返す必要があります。RESTfulサービスでブール型の質問をすることは、RPCに行き着くつまらないスループです。

今、私はあなたが見たサービスがどのように動作しているか知りません。しかし、これを解決する良い方法は、GETしようとするAccountオブジェクトのようなものを持つことです。資格情報が正しい場合は、アカウントオブジェクトを取得します。「チェック」のためだけに帯域幅を無駄にしたくない場合は、同じリソースでHEADを実行できます。

アカウントオブジェクトは、個別のリソースを作成するのが難しいだろう厄介なブール値をすべて格納するのにも最適な場所です。

401は、リクエストが認証ヘッダーフィールドを必要とし、認証が失敗した場合にのみ送信されます。ログインAPIは認証を必要としないので、401は私の意見では間違ったエラーコードです

ここの標準に従ってhttps://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

* 10.4.2 401無許可

リクエストにはユーザー認証が必要です。応答には、要求されたリソースに適用可能なチャレンジを含むWWW-Authenticateヘッダーフィールド（セクション14.47）を含める必要があります。クライアントは適切なAuthorizationヘッダーフィールド（セクション14.8）を使用してリクエストを繰り返すことができます（MAY）。要求にすでに認証資格情報が含まれている場合、401応答は、それらの資格情報の認証が拒否されたことを示します。401応答に前の応答と同じチャレンジが含まれていて、ユーザーエージェントが少なくとも1回は認証を試みている場合、エンティティには関連する診断情報が含まれている可能性があるため、ユーザーは応答で指定されたエンティティを提示する必要があります（SHOULD）。HTTPアクセス認証については、「HTTP認証：基本およびダイジェストアクセス認証」[43]で説明されています。*

適切なエラーメッセージとともに409を返します。