3

私たちは REST サービスを作成していますが、誰かが存在しない親 ID を持つリソースを要求した場合にどうするかについて議論があります。

例: 会社に関連付けられている人物のリストを要求しているため、GETID は 1 ですが、その会社 ID は存在しません。

HTTP 204 (No Content)REST の定義では、仕様に従って、HTTP の不正な要求は不正な形式の構文のみを対象としているため、単純に空のリスト (結果として ) を返すことが示されていると主張します。

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

構文が正しくないため、サーバーは要求を理解できませんでした。クライアントは、変更なしでリクエストを繰り返すべきではありません。

解釈すべきエラーがなかったことも明らかだと思います。リクエストしているリソースは存在しません。

ベストプラクティスについて考えていますか？

ここに SO の議論があります: HTTP 400 (bad request) for logical error, not malformed request syntaxですが、もう少し抽象的ですが、これを投稿するか、単にその質問を使用するかで迷っています。

4

3 に答える 3

6

もしあなたがそうするなら

GET /company/1

ID 1 の会社が存在しない場合、適切な HTTP ステータス コードは 404 - 見つかりません。

しかし、あなたがそうするならば、

GET /companies?id=1

次に、200 と空の企業リストを返します。

于 2011-09-03T00:36:30.030 に答える
3

204 はエラー コードではなく、成功コードですが、それは問題です。空のリストではあまり見られませんが、成功した DELETE など、応答する意味のあるコンテンツがないだけの成功応答です。たとえば、JSON を返す場合、コンテンツが空の 200[]は結果の空のリストに期待されるものです。ただし、あなたの場合にそれを使用することは間違っているとは思いません。

404 Not Found は、説明したケースのより一般的なエラーです。構文エラーではないことは正しいので、400 は適切ではありませんが、実際にはリソースが存在しません。404 Not Found は正確な応答です。

しかし、200、204、および 404 のいずれかを選択する際の正解は、場合によって異なります。問題は、それがエラーかどうかです。404 はより表現力があります (クライアントはそのような会社が存在しないことを知ることができます) が、表現力とセキュリティを交換することができます。つまり、その ID を持つ会社が存在するかどうかをクライアントが判断できないことは良いことです。

于 2011-09-04T04:37:22.603 に答える
0

キャッシングはどうですか？200 のみがキャッシュされ、204 と 404 はキャッシュされません。これが重要な場合、空のリストを持つ 200 は問題ないようです。空の単一要素についてはどうですか?

于 2012-07-19T21:06:24.913 に答える