Agreed. This is pretty straightforward basic stuff.
However, I do find some people wanting to differentiate in an API between an invalid path and a path that "looks right" but references some identifier that doesn't exist. This comes about from a number of flaws in thinking:
1) /Books is a resource. /Books/1234 is a resource. There is nothing other than our pre-conceived notions about Unix directory paths that says they are in any way related. URLs are opaque.
2) There is an implicit assumption that the part of the path following /Books/ is the id of a book. That is, it's a URL template. URLs are opaque.
3) Even if there is a relationship between the two resources, any explicit hypermedia links between them establish that relationship. If I were given the URL /Books then I could use a hypermedia link to traverse from there to any of its collection of books, which includes the one with an id of 1234. If I were given the /Books/1234 URL then I could use a hypermedia link to traverse up to the collection list. What does the "H" in HTTP stand for?
Now, if you want an error to differentiate between a path that's not valid in your API and a non-existent identifier, you still return 404 but possibly add a response entity to the invalid path case along the lines of:
404 Not Found
Invalid path: /Bools
404 Not Found
No book with id: 1234