About the Author
Leonard Richardson (http://www.crummy.com/) is the author of the Ruby Cookbook (O'Reilly) and of several open source libraries, including Beautiful Soup. A California native, he currently lives in New York.
An internationally known author and lecturer, Mike Amundsen travels throughout the United States and Europe consulting and speaking on a wide range of topics including distributed network architecture, Web application development, Cloud computing, and other subjects. His recent work focuses on the role hypermedia plays in creating and maintaining applications that can successfully evolve over time. He has more than a dozen books to his credit and recently contributed to the book "RESTful Web Services Cookbook" (by Subbu Allamaraju). When he is not working, Mike enjoys spending time with his family in Kentucky, USA.
Sam Ruby is a prominent software developer who is a co-chair of the W3C HTML Working Group and has made significant contributions to many of the Apache Software Foundation's open source software projects. He is a Senior Technical Staff Member in the Emerging Technologies Group of IBM.
Most helpful customer reviews
39 of 40 people found the following review helpful.
The best I could find....
... But still not great, unfortunately. The author puts a lot of effort into discouraging people from creating their own media types, link relations, etc. then spends half of the time telling us why we should use two "standard" formats that the author himself has created (Collection+JSON and ALPS). Constantly switching between JSON and XML, various scheme/profile formats are also confusing. Finally, the book is a bit condescending and too futuristic for its own good: Facebook, Flickr, Twitter, etc. have got it all wrong, and the author is going to tell us how to do things "right". Except that no examples, beyond a trivial maze game, are given of how to do things he way the author believes is correct.
2 of 2 people found the following review helpful.
Good Overview - hope the errata and loose ends can be tidied up
By Amazon Customer
I appreciated the code-less look at RESTful APIs. (While it may be code-less, it begs for you to start making HTTP requests and responses all over the wild and examining the details of those in much greater detail.)
Because the book presented real URLs for the reader to see examples of API responses, there needs to be a way to indicate that the published URLs don't work or have replacements (or didn't work but have been fixed, etc.) The first place I went to look for that, and I don't think I was atypical, was in O'Reilly's errata for the book. As of December 2013 there are no items that have been moved from the "UNCONFIRMED ERRATA" category to "CONFIRMED ERRATA". Several of those unconfirmed submissions dealt with URL problems. (The "/api/" URL now returns results but the Content-Type is "application/json" : compare this with the response documented on page 18.) My impression as a reader if the errata isn't followed up on is that the author/authors aren't so concerned with the work after publication, and I suspect that's wrong in this case.
The profiles and ALPS section (Chapter 8) of the book tickled my interest, but when I looked for the "searchable repository of ALPS documents" at alps.io, it looked like that site hasn't quite firmed up.
Despite the annoyances above, I was happy with the content of the book and would recommend it. High points for me include: detail presented in the "Seven-Step Design Procedure" and that it turned me on to OData.
10 of 11 people found the following review helpful.
See all 22 customer reviews...
Great book on the future of the web
By Omar Diab
Fantastic book about hypermedia, a potential future for the web! I think this should be required reading for all API designers and consumers. It might not strike those who play fast and loose with code as very interesting, as its focused on good design rather than getting products out in record time, but I think it's something we should all follow.
It's very clearly written and accessible, and doesn't require too much knowledge to dive into. For reference, I started learning programming around 3 years ago through my current college major.
Here's the Cliffs Notes version:
The problem that the author approaches is that APIs these days are not consistent with one another or even with themselves. This causes several issues:
1) APIs are inflexible. Once you release them, it's very difficult to change them. This is ironic, since HTTP and the web is powerful because of its flexibility.
2) APIs are not machine-readable. You have to read prose documentation to figure out how they work, and every API is different. At the same time, API documentation is often not up to date or non-existent, and it's unscalable to expect all API developers to maintiain complete documentation for all the APIs that they ever work.
3) People create novel, non-standardized APIs for the same general tasks over and over again. There's a staggering amount of repeated work.
The hope is that following standards and imposing structure and metadata in your APIs will one day allow API clients to bridge what the author calls "the semantic gap," which amounts to making an API self-document itself by using standardized idioms and good RESTful web practices, a pattern that the author calls "hypermedia."
The book lays out the problems, solutions, and process of following good API practices clearly, as well as the kind of work that needs to happen to flesh out hypermedia. In this day and age I think anyone who is writing APIs should read this book first, for the betterment of all—programmers, users, and businesses alike.