Great question. I had originally hoped to write the book for true beginners, with near zero knowledge of REST, but I think I fell short of that goal. Midway through writing the book I re-read Richardson and Ruby's book, Subbu's cookbook, and the other O'Reilly "REST In Practice" book. They are all such great books, each with very nice approaches to teaching the "basics" of REST. So I decided to not try to re-introduce REST with more
coffee ordering metaphors, since they already did such a wonderful job.
Instead, the REST API Design Rulebook attempts to help you answer some design-oriented questions that some may still be struggling with. Such as:
When should URI path segments be named with plural nouns?Which request method should be used to update resource state? How do I map non-CRUD operations to my URIs?What is the appropriate HTTP response status code for a given scenario?How can I manage the versions of a resource's state representations?How should I structure a hyperlink in JSON?
To this end, the book introduces some new concepts that build upon our existing knowledge of REST's core modeling components (URIs, HTTP methods, and hypermedia). The book tries to apply "all" of the REST constraints to the design of programmatic interfaces, which results in an even more fine-grained set of constraints - the Rulebook's rules.
So, if you are looking for a REST API design guide that attempts to concisely and clearly motivate a specific design approach/style, then you may find my book worth reading. Thanks for the interest.