7

返される適切なステータスコードを見つけようとしていますが、これまでのところ私が考えていることは次のとおりです。

  1. GET /api/documents/1- ドキュメントが存在し、ユーザーがアクセスできる - 200 OK
  2. GET /api/documents/2- ドキュメントは存在しますが、ユーザーにはアクセス権がありません - 403 Forbidden
  3. GET /api/documents/3- ドキュメントが存在しません (アクセス権があるかどうかを確認できません) - 404 Not Found? 403禁止します？
  4. GET /api/documents/a- ID が無効です (数値である必要があります) - 400 Bad Request? 404お探しのページが見つかりませんでした？403禁止します？

現時点でのバックエンド (MongoDB を使用) の問題は、ユーザーがアクセスできるドキュメント ID のリストと照合して、ユーザーがドキュメントにアクセスできるかどうかを確認することです。リストに document_id が見つからない場合は、403 Forbidden が自動的に返されます。これにより、最初にデータベースからドキュメントをフェッチして、ユーザーがアクセスできるかどうかを確認するのを避けることができます。

ここで何がベストプラクティスになるかわかりません.より良いHTTPステータスコードを追求する必要がありますか(したがって、追加のdbリクエストを作成します)、または最後の2つのケース(3と4)でも403 Forbiddenが機能しますか?

4

2 に答える 2

11

＃3と＃4の両方に404をお勧めします。

1. GET / api / document / 1-ドキュメントが存在し、ユーザーはアクセスできます-200 OK

200が適切です。

2. GET / api / document / 2-ドキュメントが存在し、ユーザーにはアクセス権がありません-403禁止

403が適切です。

3. GET / api / document / 3-ドキュメントが存在しません（アクセスできるかどうかを確認できません）-404見つかりませんか？403禁止します？

ドキュメントは指定されたURIに存在しないため、ここでは404が適切です。

4. GET / api / document / a-idが無効です（数値である必要があります）-400 Bad Request？404お探しのページが見つかりませんでした？403禁止します？

指定されたURIにリソースが存在しないため、ここでも404が適切です。参考までに、 400は不正な形式の構文を指しが、URIと要求は構文的に完全に有効です。サーバー上に対応するリソースがないというだけです。

一般に、最初にAPIについて考え、標準のHTTPアプローチに従う必要があります。これが別の内部データベース要求を必要とするかどうかは、実装の詳細です。時期尚早の最適化、特にクライアントに直接影響を与えるような最適化は避けることをお勧めします。

于 2013-01-15T23:11:26.857 に答える
1

シナリオ 3 で意図したとおりに HTTP コードを使用し、404 を使用します (リソースが見つからないため、ユーザーはアクセス許可を持っていたはずです)。シナリオ 4 では 400 を使用します (実際には悪い要求であるため)。 ）。

実装クライアントが正確に何が問題なのかを理解するのに役立ちます。特に 404 は、多くのシステムで通常の操作 (つまり、ログイン資格情報のクエリなど) で発生するため、クライアントは要求が満たされない正確な理由を理解する必要がある場合があります。

適切なステータス コードを返すと、より多くの DB リクエストが発生することがわかりません。正当な 403 ユース ケースの 403 を返すこともできます。

于 2013-01-15T21:40:21.770 に答える