The author has tried hard to make a useful reference on REST API design, and while certain parts of the book are acceptable, overall he has failed to provide a book that I would recommend to others as a guide. It is worth reading, but more as an opportunity for critique than as a source of gospel truth.
I'll start with the major issues and then proceed to smaller ones.
The author's coverage of security and how to use cryptographic primitives to handle request security is WRONG AND DANGEROUSLY INSECURE. Do not follow his advice on how to use SHA256 or anything else crypto-related; based on his suggestions he is not qualified to give advice on these topics. If you want to keep your API traffic secure, use TLS (properly configured -- see ssllabs.com for deployment best practices and a handy validator). If you cannot use TLS for some extremely good reason, you need to read "Cryptography Engineering: Design Principles and Practical Applications" (Ferguson, Schneier, Kohno) as an introductory text on designing cryptographic protocols. If that book hasn't persuaded you to simply use TLS and benefit from the hard work of experienced cryptographers, then it will at least give you a reading list of further advanced texts to refer to when designing your own protocol (which almost certainly won't be as good as TLS 1.2).
His coverage of authentication is correct in that it suggests using a finite-lifespan token. However, the fact that it does not cover OAuth 1 or 2 is bizarre for a book published in mid-2012. This is a serious omission since OAuth 2 (or 1) is likely to be a good fit for many modern REST APIs.
His coverage of HTTP PUT is incorrect. Using PUT to update part of a resource is WRONG as per the spec. See RFC 2616 9.6 (https://tools.ietf.org/html/rfc2616#section-9.6) for the RFC's coverage of HTTP PUT and RFC 5789 (https://tools.ietf.org/html/rfc5789) for HTTP PATCH. HTTP PUT may only completely replace the resource stored at a given URL, so his explanation of how to perform partial updates with HTTP PUT is not following the HTTP spec.
He does not cover matrix params at all, which is a shame as they are a useful option for doing pagination. His header-based approach is fine, but matrix params are right there in the HTTP spec as means of pagination.
His assertion that XML is better for large data sets due to easier streaming parsing is dubious. His recommended solution for JSON streaming involves generating invalid JSON. Streaming JSON parsers are no different from streaming XML parsers, and either format can be parsed in a streaming fashion.
I have other minor quibbles that I won't get into but they're just differences of opinion. The issues I've described above are basic factual errors or omissions.