「結果なし」はRESTfulレスポンスのエラーになりますか？

例について説明します
。パン屋のAPIの作成を開始します。APIを使用すると、ユーザーはを使用して自家製ミントチョコレートチップクッキーなどのベーキング製品のカタログを検索できますapi.examplebakery.com/search?q=.....。

誰かがこれを使って名前の付いた製品を探しますが、pineapple-banana flavoured cookies明らかに結果が見つかりません。

これはエラーとして返されるべきですか？検索は失敗せず、APIが検索し、Cookieが見つからないという結論に達しました。404APIが実際に見つかったため、APIはを返すべきではありません。

結果がある場合、出力は（コメントに基づくJSON）リストです。結果のないクエリの場合、出力はまったく同じである必要があります。リストsimpleには、0個のアイテムが含まれています。

だからあなたの応答が通常これなら：

{
    "results": [
        {
            "name": "Pancakes",
            ....
        },
        {
            "name": "French Fries",
            ....
        }
    ]
}

次に、結果が0のクエリの場合、次のようになります。

{
    "results": []
}

結果の「ページ」の数、それらの「ページ」へのリンクなどに関するメタデータも含める場合は、「ページ」が1つあると言うことをお勧めします。

HTTPステータスは、結果がある場合と同じである必要があります- 200 OK。

204 No Contentオプションのように思えるかもしれませんが、実際には「コンテンツ」、つまり空のリストを返すためではありません。空のリストが「コンテンツ」としてカウントされないと感じた場合、つづりの提案を提供するために応答を修正したらどうでしょうか。応答の中核はまだ空のリストですが、今ではさらに「コンテンツ」があります。

HTTPステータスコードに関するより有用な情報については、jpmc26の回答を読む価値があります。

HTTPコードを決定するときは、常に次の質問をする必要があります。

任意のクライアントが応答でできること/すること/すべきことは何ですか？

1. クライアントは常に応答を失敗として扱うべきですか？次に、問題がクライアントの入力であるかサーバーのプロセスであるかに応じて、4xxまたは5xxが必要です。
2. クライアントは代わりにどこかでリクエストを行う必要がありますか？その後、3xxはあなたのためです。
3. サーバーは、クライアントが要求した（成功した）ことをしましたか？それは2xxです。

応答コードが最初に含まれる範囲を常に決定してください。そうすることで、オプションとしての多くの応答コードが不要になり、（さらに重要なことですが）コードのセマンティクスに従うことがはるかに簡単になります。コードの各カテゴリが表すものの説明については、HTTPコードのドキュメントの最初のセクションを参照してください。

この場合、クライアントは、有効な既存のエンドポイントからフィルターを与えられた結果のリストを要求し、それにアクセスするための承認を持っています。サーバーは要求を処理し、返す適切なデータ（アイテムなし）を決定できたため、要求は成功しました。彼らが与えたフィルターがすべての結果をフィルターで除外したということが起こります。これは一部のクライアントにとって期待される結果になる可能性があるため、これがクライアントが望んでいたものかどうかを判断するのはサーバー次第ではありません。クライアントコードにとってなんらかの問題がある場合、適切に判断、確認、処理するのはクライアントの責任です。したがって、これは明らかに2xxです。

質問は、「2xxはどれですか？」です。これは、サーバーの応答方法によって異なります。

• 他の回答で説明されているように、空のリストの表現を送り返しますか？その場合、200が必要です。200は、サーバーで問題が発生せず、クライアントが消費する結果の表現があることを意味します。これはおそらく、結果があるかどうかに関係なく応答を解析し、空のリストを自分で処理する方法を見つけることができる消費者に応答する最も便利な方法です。
• ここでは、204は意味的に間違っていませんが、メッセージ本文なしで応答する必要があります。これは、すべてのクライアントコードが異なるHTTPコード（または、少なくともメッセージ本文の欠如）を明示的にチェックし、それらを個別に処理する必要があることを意味します。これは不便であり、クライアントの振る舞いが悪くなる可能性が高くなります。

その他はまったく適用されません。

• 201は問題外です。永続的なリソースを作成しておらず、作成したリソースに場所を返していません。
• 202は問題外です。要求が完了しました。バックグラウンドで処理されていません。
• 203は、権限のあるサーバーとクライアントの間で応答が変更されたことを意味します。RESTfulインターフェイスは権限のあるサーバーであるため、ここでは当てはまりません。
• 205は意味がありません。クライアントが何かを消去または更新する必要はありません。
• 206は、複数の応答で大きなリソースを返すように設計されているようです。また、クライアントが要求することを尋ねる内容の一部のためにヘッダに（クエリ文字列を経由して改ページが対象となりませんので）。ここでは適用されません。

したがって、200または204のいずれかである必要があり、200はより単純で堅牢なクライアントコードにつながる可能性が高くなります（特に、空のリストを含む一貫した応答構造を使用する場合）。

いいえ。404を使用して「クエリは処理されましたが、一致しなかった」ことを示すのは、次の理由によりひどいです。

• 例外処理に基づく条件付きフロー（つまり、例外的でない結果を強制して、パフォーマンスが悪く扱いにくいクライアントで例外を作成および処理します）

• 「実際の」ページ間の曖昧さが見つかりませんでした。エンドポイントに間違ったエラーを入力しました

覚えておくべきことは、メッセージをデシリアライズするクライアントが常に存在し、そのクライアントが返すものが重要であることです。シリアル化ではありません。

クライアントがnullを返す必要がある場合は、nullのシリアル化を使用します。クライアントが空の配列を返す必要がある場合は[]を使用し、クライアントがエラーをスローする場合は500を使用してエラーメッセージを渡す

@Ewanの非常に良い答えを超えて：

クエリが結果のセットを返す種類である場合、空のセットは論理的には1つまたは複数のセットと同じくらい適切です。一般的に、@ Ewanが述べている理由から、空のセットをエラーに変更することは害よりも害が大きく、単に不要です。

クエリが特定のシングルトンを検索して返す種類（たとえば、IDによる完全一致など）を返す場合、論理的に適切な応答は見つかりません。

データが返されない場合、コードは特別なアクションを実行する必要があると想定していますが、そうでない場合もあります。コードは単に製品数を探しているか、結果をリストまたは任意の数に追加しているだけかもしれません。実際にエラーがある場合にのみ、ユーザーに「エラー」を与える必要があります。

APIを使用する場合、クライアントとして「エラー」ケースとは異なる「成功」ケースを処理する必要があります。私には選択肢がありません。したがって、クライアントが異なる扱いをしたい状況ではエラーを返し、クライアントが同じ扱いをしたい状況では成功を返す必要があります。

理論上、0、1、200などの任意の数の結果を返すクエリを実行する場合、APIがすべての結果の完全なリストを提供するたびに「成功」​​を返す必要があります。そしておそらく、多くの結果がある場合には、過剰なサイズを避けるために結果の部分的なリストを返して、他の結果を取得する方法が合意されています。それは、クライアントとして、私はしばしば、より多くの結果の場合のように結果がゼロの場合を扱いたいからです。違う扱いをするかもしれませんが、強制されたくはありません。

値を検索する場合は異なります。ちょうど1つの結果、つまり探している値を期待しています。そして、私がやりたいことを意味のある方法で続けるために、その結​​果が必要です。ここでは、値が存在しない場合にステータス404を返す方がはるかに受け入れられます。とにかくそのケースを異なる方法で処理する必要があるからです。

要約：クライアントがゼロから大きな数までの任意の数の結果を期待している場合、すべての結果が配信されていれば、数がゼロであっても「成功」を返します。クライアントが結果を1つだけ期待している場合、結果が見つかった場合は成功を返し、結果が見つからない場合はエラーを返します。