[解決済み] RESTfulログインの失敗。401またはカスタムレスポンスを返す

質問

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

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

このWebサービスにおける他のすべてのレスポンスは、JSON形式で提供されます。

問題は、単に与えられたユーザー名/パスワードが有効かどうかを調べるために Web サービスに問い合わせるとき、Web サービスは常に成功または失敗を伝える JSON データで応答すべきか、あるいは、良い認証情報には HTTP 200 を、悪い認証情報には HTTP 401 を返すべきかということです。

私が質問する理由は、他のいくつかの RESTful サービスは、資格情報が有効かどうかを尋ねているときでさえ、悪い資格情報のために 401 を使用するからです。 しかし、私の理解では、401 レスポンスは、有効な認証情報なしでアクセスすることが想定されていないリソースを表しています。 しかし、ログインリソースの目的は、あなたの認証情報が有効であるかどうかを伝えることなので、ログインリソースは誰でもアクセスできるようにすべきなのです。

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

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

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

myservice.com/are/these/credentials/valid

は決して 401 を返しません。なぜなら、その特定の URL (リクエスト) は有効なクレデンシャルの有無にかかわらず認証されているからです。

これに関して、一方的に正当な意見を聞きたいと思います。 これを処理する標準的な方法は何でしょうか、また、これを処理する標準的な方法は論理的に適切でしょうか。

どのように解決するのか？

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

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

あなたの混乱した myservice.com/are/these/credentials/valid についてあなたが混乱しているのは、RESTでブール値のリクエストをすることは、RESTfulな制約によって間違っていることが多いという事実に基づいていると思います。すべてのリクエストはリソースを返すべきです。RESTfulなサービスでbooleanな質問をすることは、RPCへのスリップダウンになります。

さて、あなたが調べたサービスがどのように振る舞っているかはわかりません。しかし、これを解決する良い方法は、アカウントオブジェクトのようなものを用意し、それをGETしようとすることです。もし認証情報が正しければ、アカウントオブジェクトを取得することができます。

アカウントオブジェクトは、個々のリソースを作成するのが面倒な、厄介なブーリアン値を保存するのにも良い場所です。