- Paperback: 406 pages
- Publisher: O'Reilly Media; 1 edition (September 30, 2013)
- Language: English
- ISBN-10: 1449358063
- ISBN-13: 978-1449358068
- Product Dimensions: 7 x 0.8 x 9.2 inches
- Shipping Weight: 1.8 pounds (View shipping rates and policies)
- Average Customer Review: 3.3 out of 5 stars See all reviews (23 customer reviews)
- Amazon Best Sellers Rank: #579,847 in Books (See Top 100 in Books)
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
RESTful Web APIs: Services for a Changing World 1st Edition
Use the Amazon App to scan ISBNs and compare prices.
Frequently bought together
Customers who bought this item also bought
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.
If you are a seller for this product, would you like to suggest updates through seller support?
Top customer reviews
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.
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.
The book seems telling or teaching readers how to design restful API using some standards (collections+json), but I do not buy it. The book said that there are so many different restful APIs, e.g., twitter API, facebook API, etc, which is a problem, but I do not see the rational why different companies have to design APIs in a common way (unless they have some need to interconnect). On the other hand, I see some problems using e.g., collectoins+json, e.g., not flexible enough, not concise enough.
The example maze throughout the book is hard to follow, or not that interesting.
I cannot justify if the book tells really valid points, but I just do not get what I expected. It may be the case that it is just not for me.