8

まず、関連する投稿をいくつか読みました。

しかし、ここで質問と考えを提起する必要があると思います。GET を使用して「まだ準備ができていません。後で再試行してください」リソースをクエリするための REST API の HTTP ステータス コードは何ですか? たとえば、クライアントは、次の URL に対して HTTP GET を作成して、将来 (!) に発生するすべてのローカル ニュースをクエリしようとします。 ?

これらは、私が検討した http ステータス コード、その rfc 定義、および私が完全に満足できない理由です。

  • 3xx リダイレクト。コメント: リダイレクト先のリンクが他にないため、オプションではありません。

  • 503 Service Unavailable: サーバーは現在、サーバーの一時的な過負荷またはメンテナンスのため、要求を処理できません。つまり、これは一時的な状態であり、少し遅れて緩和されるということです。既知の場合、遅延の長さは Retry-After ヘッダーで示される場合があります。コメント: 再試行動作は望ましいものですが、意味的には状況はサーバーのせいではないため、すべての 5xx が奇妙に見えます。

  • 4xx クライアント エラー。コメント: 有望に見えます。下記参照。

  • 413 要求エンティティが大きすぎます: 要求エンティティが、サーバーが処理しようとしている、または処理できるよりも大きいため、サーバーは要求の処理を拒否しています。... 条件が一時的なものである場合、サーバーは Retry-After ヘッダー フィールドを含めて、それが一時的であることを示し、クライアントが再試行できる時間後に含める必要があります。コメント: 再試行の動作は望ましいものですが、「エンティティが大きすぎます」という部分は誤解を招く可能性があります。

  • 417 期待に失敗しました: このサーバーは、Expect 要求ヘッダー フィールド (セクション 14.20 を参照) で指定された期待に応えることができませんでした。コメント: したがって、Expect リクエスト ヘッダーが原因である必要があり、私の場合には当てはまりません。

  • 406 Not Acceptable: The resource ... リクエストで送信された Accept ヘッダーによると、受け入れられません。コメント: Accept リクエスト ヘッダーが原因で、私の場合には当てはまりません。

  • 409 Conflict: リソースの現在の状態と競合するため、要求を完了できませんでした。このコードは、ユーザーが競合を解決してリクエストを再送信できると予想される状況でのみ許可されます。... 競合は、PUT 要求への応答で発生する可能性が最も高くなります。コメント: これは近いです。私のケースは PUT に関するものではありませんが、実際には競合が原因ではありません。

  • 404 Not Found: サーバーは Request-URI に一致するものを見つけられませんでした。コメント: 技術的には、私の URL パス ( http://example.com/news ) は存在します。問題の原因となっているパラメーターです。この場合、404 の代わりに空のコレクションを返す方がおそらく適切です。

  • 403 Forbidden: サーバーはリクエストを理解しましたが、リクエストの実行を拒否しています。承認は役に立たず、要求を繰り返すべきではありません。コメント: 通常、これは制限されたリソースで使用されることになっていますか?

  • 400 Bad Request: 構文が正しくないため、サーバーが要求を理解できませんでした。クライアントは、変更なしでリクエストを繰り返すべきではありません。コメント: 私の場合はそうではありません。私のサーバーはリクエストを理解しています。その構文は良いですが、意味だけが悪いです。

  • 2xx 成功。コメント: 4xx が機能しない場合、2xx はどうですか? 下記参照。

  • 200 わかりました。コメント: 結構です。では、応答本文には何を含める必要がありますか? null または [] または {} または {"date": "2099-12-31", "content_list": null} または ... どちらがより直感的ですか? 一方で、マイナーな「将来のニュース」エラーと、より一般的な「すべてのクエリ基準は良好で、今日はニュースがない」という状況を明確に区別する方法を好みます。

  • 202 Accepted: リクエストは処理のために受け入れられましたが、処理は完了していません。要求は、最終的に処理される場合と処理されない場合があります。コメント: GET リクエストで 202 を使用できるのであれば、許容されます。次に、200 コメントを参照してください。

  • 204 No Content: サーバーはリクエストを実行しましたが、エンティティ本体を返す必要はありません。コメント: GET リクエストで 204 を使用できるのであれば、許容されます。これが 202 と 200 のどちらより優れているかはわかりません。

  • 2xx の詳細:コメント: すべての 2xx 応答がどこかにキャッシュされる可能性が高いと思います。しかし、私の場合、「明日のニュース」に対して空の本文を返す場合、それをキャッシュしたくありません。わかりました、「キャッシュなし」ヘッダーを明示的に指定すると役立つはずです。

あなたの考え？

4

2 に答える 2

4

404 を使用します。

それに対するあなたの反対は、クエリ文字列を含まないというURIの一般的な理解に基づいています。「同じハンドラーにマップする複数の URI があるため」、「私のリソースは実際に存在し、クエリ文字列引数によってパラメーター化されているだけです。」

これは正しくありません。URI 仕様自体がセクション 3.3 で述べているように (強調は私のものです) 、

「パスコンポーネントには、通常は階層形式で編成されたデータが含まれており、非階層クエリコンポーネント(セクション 3.4) のデータとともに、URI のスキームと命名機関 (存在する場合) の範囲内でリソースを識別するのに役立ちます。 "

リソースは URI によって識別され、絶対 URI の任意の部分が変更されると、個別のリソースが識別されます。やめるように言われるまで、1日1回、知っている人全員にツイートしてください。したがって、404は完全に一致します。「404 (Not Found) ステータス コードは、オリジン サーバーがターゲット リソースの現在の表現を見つけられなかったか、存在することを開示する意思がないことを示します。」

于 2013-10-17T14:34:54.687 に答える
2

有効な日であるその日のニュースを取得していますが、ニュースはありません。空の本文の 200 応答、またはメディアタイプに基づいて意味のあるものは、論理的に見えるでしょう。これは、クライアントと決定したメディア タイプによって異なります。

404 は、日付形式が間違っている場合 (11 月の 45 日を要求した場合、または存在しない都市を要求した場合) により意味があります。

余談ですが、URL はhttp://example.com/news/chicago/2099-12-31の形式の方が適切です。これは取得したい特定のリソースだからです。この形式により、404 などもより明確になります。

于 2013-10-17T09:24:34.073 に答える