W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2020

Re: How to express no matching results in HTTP SEARH method?

From: Austin Wright <aaa@bzfx.net>
Date: Wed, 4 Nov 2020 13:49:49 -0700
Cc: ietf-http-wg <ietf-http-wg@w3.org>
Message-Id: <DE3B489F-34C5-461C-A34E-142C0595498C@bzfx.net>
To: Sawood Alam <ibnesayeed@gmail.com>


> On Nov 3, 2020, at 19:40, Sawood Alam <ibnesayeed@gmail.com> wrote:
> 
> Hi,
> 
> What would be an appropriate status code if the target resource of the SEARCH method wants to provide an entity to convey that the search operation yielded no results? In traditional GET-style searching, one could return a 404, would that still be an option (I doubt it as it would mean the target resource itself that performs the search is not found)?

A search result with zero results is still a resource that exists, so the status code should be 200. This is also true for `GET /search?q={query}`.

If the client expects at least one result, but none are returned, it doesn’t need a status code to figure out something’s up.

This is different from looking up a single resource by its URI. If an HTML form says to use `GET /item?id={id}` to look up a product, the response will be the actual product itself (not a query result), so either it exists at that URI (200), or it doesn’t (404).

It’s the difference between saying “Make me a list of all the books on the second shelf” (an empty list is still a list, 200) and “Get me the first book on the second shelf” (That’s an error if there’s no book there, 404).

> 
> The specification seems to suggest usage of 204, but in that case no content can be returned in the response, which may be desired in some cases. Also, 204 is a success response, which means a client might repeat the request, while a 4xx response would suggest that there is no point in repeating the request without making changes to it.

A 204 is identical to sending a 200 response with Content-Length: 0

If you want to suggest that the response is not going to change in the near future, use caching headers.

> 
> Best,
> 
> --
> Sawood Alam

Cheers,

Austin.
Received on Wednesday, 4 November 2020 20:50:05 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 4 November 2020 20:50:06 UTC