> Clients should not generally be constructing URLs by hand
I'm not sure I get this, every API doc is like "go to /users for the users and here's the methods we support, the payloads, and responses" If someone mistypes it and tried to get "/user" I want to send a 404 to be like "there is nothing here."
> In the example in the article, an application dealing with employees.
This is all very nice when your domain maps nicely to objects. My litmus tests for this is what would the semantics of mysql.net/query?db=mydb,q='select * from table;' look like.
* If the result is an empty record set should it return 404? Ew. I think it should be 200 with the response being `[]`.
* If you're not allowed to access a table should you get 403?
"Select *" is like find/ search - any API that could logically match multiple entities and return a list should stick to 200 in the case of an empty set.
But for an API designed to return just the specific single resource requested there's a decent case for a 4xx status code if it doesn't exist (400/404/410/422 all being justifiable depending on your preferences).
I'm not sure I get this, every API doc is like "go to /users for the users and here's the methods we support, the payloads, and responses" If someone mistypes it and tried to get "/user" I want to send a 404 to be like "there is nothing here."
> In the example in the article, an application dealing with employees.
This is all very nice when your domain maps nicely to objects. My litmus tests for this is what would the semantics of mysql.net/query?db=mydb,q='select * from table;' look like.
* If the result is an empty record set should it return 404? Ew. I think it should be 200 with the response being `[]`.
* If you're not allowed to access a table should you get 403?