[ilovefood]

The article is good, and I get the point. However, from experience, this:

> POST on /queries/enlisted-students-on-joining-date/version/1 { "date": "2023-09-22" } to retrieve all students that joined on a given date.

always ends up in a complete and absolute mess, where every possible query gets it's own random name, different parameters, ending up with duplicates all over the place. Also, while it can be possible to cache these POST requests (responses), it's additional work and more friction compared to REST. I'm not convinced the tradeoff is worth it in this particular case.

All in all, I don't know if the current proposal can be an alternative either but the idea of a "REST-lite" goes in the right direction and it's a great start.

However this is a complete no for me:

> When a requested student is nonexistent, your API can return 200 OK HTTP status code with a { "user": null, "message": "No user exists with the specified ID" } response body.

If nothing is found, I want a 404! :D

[benrow]

I like the convention:

- 404 if resource requested by id

- 200 with empty list of results if it was a 'search' type request with params (not referring directly to an id)

[Banditoz]

What about 204? https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/204

[benrow]

I still prefer 200 with an empty list for the 'no results' case. The same client code works, rather than having to code for 204.

- If I query for an identifier which doesn't exist - Server replies 404, this should fall into my error handling as there's a data inconsistency

- If I query say like ?category=automotive&price=1 and I get a 200 containing a json body in which there's an empty list of matches, then my client code can handle 0 matches as well as 1 or 10 with no special handling.

[tuetuopay]

this is the standard we have company-wide and it works pretty well, unless you make a mistake in the uri (like picking up the wrong api version). however, all apis will return some info on their root, so it's easy to distinguish and troubleshoot

[pdonis]

404 means that there is no resource at the requested URI. But in the case you're discussing, there is a resource at the requested URI; it's just a resource that says there's no user there, instead of a resource that gives data for a user.

In other words, using 404 the way you describe conflates two different things: an invalid user URI (maybe the range of possible user IDs is restricted, or you typed in the URI wrong) and a valid user URI that just doesn't have a user there at the time you made your request. But you probably don't want those two things to be conflated; you want them to be distinguished. That's the article's point.