- Taschenbuch: 404 Seiten
- Verlag: O'Reilly and Associates; Auflage: 1 (27. September 2013)
- Sprache: Englisch
- ISBN-10: 1449358063
- ISBN-13: 978-1449358068
- Größe und/oder Gewicht: 17,9 x 2,1 x 23,3 cm
- Durchschnittliche Kundenbewertung: Schreiben Sie die erste Bewertung
- Amazon Bestseller-Rang: Nr. 8.381 in Fremdsprachige Bücher (Siehe Top 100 in Fremdsprachige Bücher)
RESTful Web APIs (Englisch) Taschenbuch – 27. September 2013
|Neu ab||Gebraucht ab|
Wird oft zusammen gekauft
Kunden, die diesen Artikel gekauft haben, kauften auch
Es wird kein Kindle Gerät benötigt. Laden Sie eine der kostenlosen Kindle Apps herunter und beginnen Sie, Kindle-Bücher auf Ihrem Smartphone, Tablet und Computer zu lesen.
Geben Sie Ihre Mobiltelefonnummer ein, um die kostenfreie App zu beziehen.
Wenn Sie dieses Produkt verkaufen, möchten Sie über Seller Support Updates vorschlagen?
Über den Autor und weitere Mitwirkende
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.
Welche anderen Artikel kaufen Kunden, nachdem sie diesen Artikel angesehen haben?
Die hilfreichsten Kundenrezensionen auf Amazon.com
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.