This is something that depends on the interpretation of the RFC as well as the intended "protocol". If you want to be RESTish, the book with the given id is a resource and if that resource does not exist, The best response in my opinion is the 404. Giving a 200 with a null or empty response is more or less an encoding trick. The consumer will have to check the content for certain criteria first. I'll admit that checking the status code is nearly the same check, but why would I want to throw away this means of expressing something about the result and replace it with something that is not defined in the RFC? I'm my opinion, that's the way of communicating clearly.
When you imply that you don't see the database as a part of your application and rather a data repository: I totally agree, but I draw different conclusions from this. Even though the database will know whether a book exists, it does not really define whether it exists. This definition is done by the users of your system when they create books. They will not care where it is stored though, as long as no data will be lost. And if we assume that the database is consistent, a user asking for a book (represented by an UUID) that does not exist is asking for something that really does not exist. It's not just a syntactical error in the user's side. So I still think a 404 is the way to go here.
Having said that, I also have my problems with the RESTish approach of CRUD operations, as we will often want to restrict which changes a user can do at a given time in real-world applications. I do prefer going with a more CQRS-like way of having commands to perform certain operations in a resource. But that would open another large discussion.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is something that depends on the interpretation of the RFC as well as the intended "protocol". If you want to be RESTish, the book with the given id is a resource and if that resource does not exist, The best response in my opinion is the 404. Giving a 200 with a null or empty response is more or less an encoding trick. The consumer will have to check the content for certain criteria first. I'll admit that checking the status code is nearly the same check, but why would I want to throw away this means of expressing something about the result and replace it with something that is not defined in the RFC? I'm my opinion, that's the way of communicating clearly.
When you imply that you don't see the database as a part of your application and rather a data repository: I totally agree, but I draw different conclusions from this. Even though the database will know whether a book exists, it does not really define whether it exists. This definition is done by the users of your system when they create books. They will not care where it is stored though, as long as no data will be lost. And if we assume that the database is consistent, a user asking for a book (represented by an UUID) that does not exist is asking for something that really does not exist. It's not just a syntactical error in the user's side. So I still think a 404 is the way to go here.
Having said that, I also have my problems with the RESTish approach of CRUD operations, as we will often want to restrict which changes a user can do at a given time in real-world applications. I do prefer going with a more CQRS-like way of having commands to perform certain operations in a resource. But that would open another large discussion.