4

認証されたクライアントによってのみ表現を取得する必要があるRESTfulリソースがあります。認証されていないクライアントがGETリクエストを行った場合、401が返されます。

一方、認証されていないクライアントがリソースが存在するかどうかを判断できるようにしたいと思います。この場合、リソースが存在する場合はHEADリクエストが200を返し、存在しない場合は404を返すことを検討しています。

RFC 2616は、セクション9.4のHEADリクエストについて次のように述べています。

HEADリクエストに応答してHTTPヘッダーに含まれるメタ情報は、GETリクエストに応答して送信される情報と同一である必要があります。

このアプローチは適切にRESTfulと見なされますか？

別の方法として、GETおよびHEADリクエストで、存在しないリソースの場合は404を返し、リクエストが存在するがクライアントに資格がない場合は401を返すようにすることができます。

4

2 に答える 2

3

私は404/401ルートに行きます。それははるかに単純で、より直交しています。また、HEADの定義の最初の行は次のようになっているためです。

HEADメソッドはGETと同じですが、サーバーが応答でメッセージ本文を返さないようにする必要があります。

そして、これはHEADをサポートしないHTTPクライアントのための道を開いたままにします。認証されていない場合は、GETを実行するだけでリソースの存在を判断できます。HEADサポートは必要ありません。

于 2013-03-26T18:26:31.617 に答える
3

認証されていないクライアントがリソースの存在を判断できるようにする場合は、後者のオプション（存在しない場合は404、認証されていない場合は401）を使用します。その存在情報が公開されている場合、404/401が正しい応答です。

  • 404：認証されていないクライアントであるあなたに確認します。このリソースは存在しません。
  • 401：このリソースを取得するための適切な権限がないため、リクエストを拒否します。

さらに、これにより、認証されたクライアントは、適切なアクセス権があり、それが存在する場合、200のリソースをHEADすることができます。

于 2013-03-26T18:28:00.467 に答える