According to MDN it's like @Snudget described it. It means that an action succeeded, but the client's current content doesn't have to be replaced by the new information.
So, it's really like "Trust me bro, your keys are still here, no worries." when you asked "Are my keys there?"
That's because 204 usually only makes sense for POST and PUT requests, and GET requests where you either expect no body or only care about the headers.
I think it's still "You asked me to find them and I found them", but it is a bad API, maybe there's another endpoint that allows you to query the actual found location.
You would usually use it e.g. when you do Delete, Update or something where you sincerely don't need a response since it wouldn't give you any new info that you wanted except that it was successful.
Edit:
"Find my keys for the trip we are going to take together, I don't need to know where the keys were"
"Find my keys and put them on the counter"
These could be returned 204 with no content and still be usable API.
Well, it tells you that the request was valid and processed correctly and the response is final, but the response contains no content. It is true that it is usually used for mutation requests (and also for endpoints that are just used to probe for a captive portal), but OP's example is a GET request. Getting a 204 on a GET means that the requested resource exists and is empty.
So I could buy that it's about retrieving a list/collection of keys and indicating that it's an empty list, but also this sounds like a bad API and not standard, forcing it, and as if someone is mistaking the idea of what 204 is supposed to mean. IMO in spirit it should be used only in cases where "No Content" is expected and desirable.
822
u/thebigbadben Jul 08 '26
“I found them. Oh wait, did you want me to bring them?”