If you're routing like it's 1999, sure, 404.

On the other hand, if it's a CRUD app and you're filtering a list of entities by various field values? Returning that no items matched your selection (or an empty list, if an API) makes more sense than a 404, which would more appropriate for an attempt to pull up a nonexistent entity URI.

▲

Sander_Marechal 4 hours ago | parent | next [-]

There is no reason you can return that "no items matched your selection" with a 404 HTTP response code instead of a 200.

	▲	threatofrain 2 hours ago \| parent [-]
		A response code of 204 seems more appropriate but the problem is you're not allowed to send further information, which would make that descriptive response... not descriptive enough.

▲

stouset 4 hours ago | parent | prev | next [-]

The point was that returning a 404 for unexpected query strings doesn’t just happen to okay per the specs, but that there is significant historical precedent for doing so based on application design that was common in the past.

▲

brightball 4 hours ago | parent | prev [-]

Yea, empty response at a valid path. Isn’t 204 the code for it?

Lots of REST libraries that I’ve used treat any 400 response as an error so generating a 404 when for an empty list would just create more headaches.

	▲	HumanOstrich 42 minutes ago \| parent \| next [-]
		Libraries that automatically throw errors for status codes in the 400 and 500 ranges are pretty obnoxious (looking at you, axios). It adds unnecessary overhead, complexity, and bad ergonomics by hijacking control flow from the app. Responses with status codes in the 400 range are client errors, so the client shouldn't retry the same request. So a 404 is appropriate despite how annoying a library might be at handling it. Depending on which language/ecosystem you are using, there are likely more sane alternatives.
	▲	sk5t 3 hours ago \| parent \| prev \| next [-]
		204 might be acceptable if you aren’t returning an entity body to describe what is missing, but do wish to indicate the request was successful.
	▲	burnished 2 hours ago \| parent \| prev [-]
		I think the author is comfortable creating headaches for people tacking query strings onto URLs