What do you think?
Rate this book
RESTful Web Services
"Every developer working with the Web needs to read this book."-- David Heinemeier Hansson, creator of the Rails framework
"RESTful Web Services finally provides a practical roadmap for constructing services that embrace the Web, instead of trying to route around it."-- Adam Trachtenberg, PHP author and EBay Web Services Evangelist
You've built web sites that can be used by humans. But can you also build web sites that are usable by machines? That's where the future lies, and that's what RESTful Web Services shows you how to do. The World Wide Web is the most popular distributed application in history, and Web services and mashups have turned it into a powerful distributed computing platform. But today's web service technologies have lost sight of the simplicity that made the Web successful. They don't work like the Web, and they're missing out on its advantages.
This book puts the "Web" back into web services. It shows how you can connect to the programmable web with the technologies you already use every day. The key is REST, the architectural style that drives the Web. This This is the first book that applies the REST design philosophy to real web services. It sets down the best practices you need to make your design a success, and the techniques you need to turn your design into working code. You can harness the power of the Web for programmable you just have to work with the Web instead of against it. This book shows you how.
"RESTful Web Services finally provides a practical roadmap for constructing services that embrace the Web, instead of trying to route around it."-- Adam Trachtenberg, PHP author and EBay Web Services Evangelist
You've built web sites that can be used by humans. But can you also build web sites that are usable by machines? That's where the future lies, and that's what RESTful Web Services shows you how to do. The World Wide Web is the most popular distributed application in history, and Web services and mashups have turned it into a powerful distributed computing platform. But today's web service technologies have lost sight of the simplicity that made the Web successful. They don't work like the Web, and they're missing out on its advantages.
This book puts the "Web" back into web services. It shows how you can connect to the programmable web with the technologies you already use every day. The key is REST, the architectural style that drives the Web. This This is the first book that applies the REST design philosophy to real web services. It sets down the best practices you need to make your design a success, and the techniques you need to turn your design into working code. You can harness the power of the Web for programmable you just have to work with the Web instead of against it. This book shows you how.
419 pages, Paperback
First published January 1, 2007
61 people are currently reading
864 people want to read
About the author
Leonard Richardson
22books43followersLeonard Richardson is an expert on RESTful API design, the developer of the popular Python library Beautiful Soup, and a science fiction novelist.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 48 reviews
October 23, 2012
The authors certainly had their work cut out for them: how do you explain something that (near as I can tell) has yet to have even just one real-world implementation which completely satisfies the requirements?
Seriously, look at the real-world examples used in this book. Not a single one of them adhere to the four principles of Addressability, Statelessness, Connectedness, and a Uniform Interface. Some of them fail miserably at all four!
And that's a constantly recurring problem when you start looking (article by Dr. Roy Fielding, REST's creator).
So given that hurdle right off the bat, I think this is a very good introduction to a very abstract concept with some very non-abstract implementations.
While it's a bit of a strange book (on a bit of a strange topic) I believe the material covered was all extremely relevant and important. A lot of space was devoted to driving home the concept of "resources" and I was enlightened. Likewise, a lot of space was given to the use of HTTP's "uniform interface" comprised of methods such as GET, PUT, HEAD, etc. and I was enlightened.
And then some space was given to the concept of connectedness, or as some put it,
"Hypermedia as the Engine of Application State" or HATEOAS. And then I wasn't just enlightened. I was inspired. I suddenly envisioned Web-based APIs that were actually browsable by humans. And forms you could fill out to PUT a resource or DELETE a resource. At that point, I stopped just taking notes and started writing code.
Shortly after finishing this book, I completed my own first foray into RESTfulness: (the hm-json stands for "Hypermedia JSON"), a browser and a microformat that turns ordinary JSON API resources into hypermedia completely browsable and usable (including the full range of HTTP methods) by a human with a mouse and keyboard. It's a simple piece of software, really, but it's like a nice visual of what web services could be if they were to actually incorporate the hypermedia requirement of REST (and not just the pretty URLs).
But I am in danger of a serious digression. So enough about that, and back to the book:
I must criticize the source code examples. Using Ruby to call libraries to interact with RPC and REST services demonstrates absolutely nothing since the details are abstracted away. Unless I was seriously mistaken, the details were the whole point, dammit!
Also, there is way too much repetition between chapters. While it's nice to give little reminders or hints if a reader comes back to a chapter for reference months or years later, these should be kept as unobtrusive as possible. With all of the repetition, reading this straight through was a real slog. Not a painful slog, but a slog nonetheless.
I agreed with the authors' premise regarding the advantages of RESTful services over traditional XML envelope-based services. I always prefer elegance and simplicity. So I didn't mind reading about the shortcomings of SOAP and the like. But I can imagine someone being annoyed by these tangents.
I also supplemented the book with a lot of online reading and I suggest you do the same. I don't feel you really know this subject until you've read a lot of arguments for and against the various tenants of REST (and arguments about what, exactly, the various tenants of REST even are!) and have formed your own opinions about it.
In the end, it's an uneven book and it has some serious shortcomings. But I certainly learned the subject and I certainly gained a lot of insights. It may be impossible to actually create something that creator Dr. Fielding would put his stamp of approval upon, but that doesn't mean we can't all learn a great deal by trying.
Seriously, look at the real-world examples used in this book. Not a single one of them adhere to the four principles of Addressability, Statelessness, Connectedness, and a Uniform Interface. Some of them fail miserably at all four!
And that's a constantly recurring problem when you start looking (article by Dr. Roy Fielding, REST's creator).
So given that hurdle right off the bat, I think this is a very good introduction to a very abstract concept with some very non-abstract implementations.
While it's a bit of a strange book (on a bit of a strange topic) I believe the material covered was all extremely relevant and important. A lot of space was devoted to driving home the concept of "resources" and I was enlightened. Likewise, a lot of space was given to the use of HTTP's "uniform interface" comprised of methods such as GET, PUT, HEAD, etc. and I was enlightened.
And then some space was given to the concept of connectedness, or as some put it,
"Hypermedia as the Engine of Application State" or HATEOAS. And then I wasn't just enlightened. I was inspired. I suddenly envisioned Web-based APIs that were actually browsable by humans. And forms you could fill out to PUT a resource or DELETE a resource. At that point, I stopped just taking notes and started writing code.
Shortly after finishing this book, I completed my own first foray into RESTfulness: (the hm-json stands for "Hypermedia JSON"), a browser and a microformat that turns ordinary JSON API resources into hypermedia completely browsable and usable (including the full range of HTTP methods) by a human with a mouse and keyboard. It's a simple piece of software, really, but it's like a nice visual of what web services could be if they were to actually incorporate the hypermedia requirement of REST (and not just the pretty URLs).
But I am in danger of a serious digression. So enough about that, and back to the book:
I must criticize the source code examples. Using Ruby to call libraries to interact with RPC and REST services demonstrates absolutely nothing since the details are abstracted away. Unless I was seriously mistaken, the details were the whole point, dammit!
Also, there is way too much repetition between chapters. While it's nice to give little reminders or hints if a reader comes back to a chapter for reference months or years later, these should be kept as unobtrusive as possible. With all of the repetition, reading this straight through was a real slog. Not a painful slog, but a slog nonetheless.
I agreed with the authors' premise regarding the advantages of RESTful services over traditional XML envelope-based services. I always prefer elegance and simplicity. So I didn't mind reading about the shortcomings of SOAP and the like. But I can imagine someone being annoyed by these tangents.
I also supplemented the book with a lot of online reading and I suggest you do the same. I don't feel you really know this subject until you've read a lot of arguments for and against the various tenants of REST (and arguments about what, exactly, the various tenants of REST even are!) and have formed your own opinions about it.
In the end, it's an uneven book and it has some serious shortcomings. But I certainly learned the subject and I certainly gained a lot of insights. It may be impossible to actually create something that creator Dr. Fielding would put his stamp of approval upon, but that doesn't mean we can't all learn a great deal by trying.
January 28, 2008
This book while interesting, leaves much to be desired. They author is a bit scattered, and following his examples and code snips is a bit trying at times. None the less, it is an interesting read on REST style development.
October 12, 2008
Everything from OREILLY is of the highest quality. The book as you would expect is heavily biased toward REST versus an RPC architecture. I agree that one must read this book if they hope to understand all of the options in building scalable web-services.
October 25, 2018
Reading dates are approximate, as is often the case with my reviews, this time because I was reading two other programming books concurrently, and I got a bit hazy as to where one began and the other ended.
This is a straightforward tutorial on developing Webservices in the RESTful paradigm. I bought this book several years ago, when it was still warm from the presses, and when I was writing Webservices for Hewlett-Packard. It languished among my other packed-away books, in stacks of boxes, until a fortuitous box-breaking occurred while moving, revealing it (among others) to myself, begging to be finished. I finished it a couple weeks back, but it's still on my desk so that I can work back through the exercises. This is not a .NET-centric book; example code is mostly in Ruby, although toward the end examples in some other languages are offered.
I'd recommend this as Prong One of a three-pronged course in modern Web development. (Well, a fourth prong, upon which I haven't yet embarked, would entail a thorough study of HTML5, and you could add a fifth prong to delve into the details of TCP / IP and HTTP, and even a sixth to bring you up to speed on the various in-vogue Javascript libraries. But three prongs at a time is usually my limit.)
To follow my personal curriculum, use this book to become steeped in REST principles, then follow up with another contemporary O'Reilly book, RESTful .NET (to be reviewed next). That should cover the programmable Web fairly nicely, after which you'll want to use Professional ASP.NET Design Patterns (WROX, to be reviewed shortly) to cover the human-readable Web.
With the material thusly covered, I'm preparing my own comprehensive Web component suite, adherent to various standard design patterns, upon which I'll hang the next three, aforementioned prongs, which are UI-centric. Wish me luck in my private contracting endeavors.
This is a straightforward tutorial on developing Webservices in the RESTful paradigm. I bought this book several years ago, when it was still warm from the presses, and when I was writing Webservices for Hewlett-Packard. It languished among my other packed-away books, in stacks of boxes, until a fortuitous box-breaking occurred while moving, revealing it (among others) to myself, begging to be finished. I finished it a couple weeks back, but it's still on my desk so that I can work back through the exercises. This is not a .NET-centric book; example code is mostly in Ruby, although toward the end examples in some other languages are offered.
I'd recommend this as Prong One of a three-pronged course in modern Web development. (Well, a fourth prong, upon which I haven't yet embarked, would entail a thorough study of HTML5, and you could add a fifth prong to delve into the details of TCP / IP and HTTP, and even a sixth to bring you up to speed on the various in-vogue Javascript libraries. But three prongs at a time is usually my limit.)
To follow my personal curriculum, use this book to become steeped in REST principles, then follow up with another contemporary O'Reilly book, RESTful .NET (to be reviewed next). That should cover the programmable Web fairly nicely, after which you'll want to use Professional ASP.NET Design Patterns (WROX, to be reviewed shortly) to cover the human-readable Web.
With the material thusly covered, I'm preparing my own comprehensive Web component suite, adherent to various standard design patterns, upon which I'll hang the next three, aforementioned prongs, which are UI-centric. Wish me luck in my private contracting endeavors.
October 24, 2017
The book has quite a bit of good info, but (and the items below are what lead to 2 stars in my opinion):
- It assumes you have a lot of background knowledge on computer networking and world wide web.
- It keeps repeating (and fascinating about) RESTful services principles over and over again in every chapter, to the point that it becomes tedious.
And above all:
- The book has been written in 2007, and almost all technologies and source codes used in it are out dated now (in 2017) and of little practical value.
Hence, if you have the time and you feel like learning a bit more about REST principles and advantages, go ahead and read the non-code and non-technical parts of the book, but don't bother with the details and only look at it from a high level perspective.
- It assumes you have a lot of background knowledge on computer networking and world wide web.
- It keeps repeating (and fascinating about) RESTful services principles over and over again in every chapter, to the point that it becomes tedious.
And above all:
- The book has been written in 2007, and almost all technologies and source codes used in it are out dated now (in 2017) and of little practical value.
Hence, if you have the time and you feel like learning a bit more about REST principles and advantages, go ahead and read the non-code and non-technical parts of the book, but don't bother with the details and only look at it from a high level perspective.
March 24, 2017
This book gives a very good introduction to the concepts underlying the RESTful way to design Web Services and explains in details the benefits of a Resource Oriented Architecture. The main issue that I noticed is that the examples are kind of outdated. But, it is actually pretty cool to see how much the web evolved in the past 10 years.
If you come across a cheap copy of this book, I would recommend to read the chapters that are about the general principles of the resource oriented architecture and the examples of how to design a well thought web service. The authors are going in great details about why the type of architecture they are advising for makes sense and compare it with other possible designs. It is extremely useful to understand the value of these principles.
If you come across a cheap copy of this book, I would recommend to read the chapters that are about the general principles of the resource oriented architecture and the examples of how to design a well thought web service. The authors are going in great details about why the type of architecture they are advising for makes sense and compare it with other possible designs. It is extremely useful to understand the value of these principles.
March 26, 2018
Touches on the basic issues of Restful API design, but the book is not efficient, lots of repetition and poor writing style.
May 12, 2019
Good introduction of RESTful APIs, if you just want to know the basics, read just the first chapters, no need to go through the whole book
May 23, 2009
This is both a manifesto for what the authors term 'REST-Oriented Architecture' (ROA), and a technical dive into the mechanics and semantics of REST. It comes as a big breath of fresh air after years of being harangued by the putative benefits of Service-Oriented Architecture (SOA) with its plethora of web-service standards centered on XML, SOAP, and WSDL, and the many competing and largely incompatible SOA toolkits.
REST (or ReST) stands for 'Representational State Transfer', a term and concept introduced by Roy Fielding nearly a decade ago. The basic idea is that, in current practice, the www consists in large part of interconnected resources where the connections are implemented by the basic HTTP methods of GET and POST, and resource representation is typically HTML, heavily annotated and marked-up, and difficult to work with programmatically. But HTTP, combined with suitably chosen URIs, and combined with more program-oriented representations such as XML and JSON, can provide us the combined advantages of the interconnected web and programmable 'services'.
In the ReST model the HTTP methods (GET, PUT, POST, DELETE, and maybe HEAD) are the only methods that would be exposed by a web 'service'. The service exposes URI (universal resource identifiers) for each of the resources provided by the service (a possibly unbounded set of resources), and the methods are applied to those URIs. Each resource can have one or many representations - for example, as XML, JSON, HTML, PDF, etc. There are multiple ways of selecting a representation: for example, adding an 'Accept' header to the HTTP request, or adding some kind of 'qualifier' to the basic URI (for example, a .xml or .pdf suffix).
Representations can (and in the view of the authors, should) provide links to related resources - in fact this ability to link to other resources is the source of much of the power and attractiveness of the ReST model. This ability to identify resources by URI sets ROA apart from SOA. As the authors note, an SOA application normally has few URIs, sometimes only one. So it is literally impossible for the result of a service call to identify the related entities (I can't call them resources) for that call. Instead, the client-side programmer must understand the documentation (possibly by poring over the service's WSDL description) to know how to accomplish any given task. Unless the service designers used great care, the service calls within the SOA application bear little relationship to one another, so understanding some portion of the API provides no great insight into the remainder of the API. The situation is (or can be) different in an ROA application: knowing the set of basic resource types gives immediate knowledge of how to access any particular resource instance. Knowing the relationships between resources (for example, which resources are containers, which resource types are related to other resource types) gives knowledge of how to 'navigate' the application - without the service provider having to document every detail of that navigation.
This is exciting stuff. But there are many challenges. At the low end of the scale, there is the issue that browsers know only the GET and POST methods - not DELETE, PUT, and HEAD. So POST has to be overloaded to provide the functionality of PUT and DELETE. At the top end of the scale, it is not clear in any given case what resources should be exposed and what their representation should be. We need a book entitled 'Resource Oriented Design Patterns' to fill this gap.
In the meantime, RESTful Web Services is a terrific guide to developing web applications.
REST (or ReST) stands for 'Representational State Transfer', a term and concept introduced by Roy Fielding nearly a decade ago. The basic idea is that, in current practice, the www consists in large part of interconnected resources where the connections are implemented by the basic HTTP methods of GET and POST, and resource representation is typically HTML, heavily annotated and marked-up, and difficult to work with programmatically. But HTTP, combined with suitably chosen URIs, and combined with more program-oriented representations such as XML and JSON, can provide us the combined advantages of the interconnected web and programmable 'services'.
In the ReST model the HTTP methods (GET, PUT, POST, DELETE, and maybe HEAD) are the only methods that would be exposed by a web 'service'. The service exposes URI (universal resource identifiers) for each of the resources provided by the service (a possibly unbounded set of resources), and the methods are applied to those URIs. Each resource can have one or many representations - for example, as XML, JSON, HTML, PDF, etc. There are multiple ways of selecting a representation: for example, adding an 'Accept' header to the HTTP request, or adding some kind of 'qualifier' to the basic URI (for example, a .xml or .pdf suffix).
Representations can (and in the view of the authors, should) provide links to related resources - in fact this ability to link to other resources is the source of much of the power and attractiveness of the ReST model. This ability to identify resources by URI sets ROA apart from SOA. As the authors note, an SOA application normally has few URIs, sometimes only one. So it is literally impossible for the result of a service call to identify the related entities (I can't call them resources) for that call. Instead, the client-side programmer must understand the documentation (possibly by poring over the service's WSDL description) to know how to accomplish any given task. Unless the service designers used great care, the service calls within the SOA application bear little relationship to one another, so understanding some portion of the API provides no great insight into the remainder of the API. The situation is (or can be) different in an ROA application: knowing the set of basic resource types gives immediate knowledge of how to access any particular resource instance. Knowing the relationships between resources (for example, which resources are containers, which resource types are related to other resource types) gives knowledge of how to 'navigate' the application - without the service provider having to document every detail of that navigation.
This is exciting stuff. But there are many challenges. At the low end of the scale, there is the issue that browsers know only the GET and POST methods - not DELETE, PUT, and HEAD. So POST has to be overloaded to provide the functionality of PUT and DELETE. At the top end of the scale, it is not clear in any given case what resources should be exposed and what their representation should be. We need a book entitled 'Resource Oriented Design Patterns' to fill this gap.
In the meantime, RESTful Web Services is a terrific guide to developing web applications.
December 22, 2013
I began reading "Restful Web Services" while researching technical solutions for a web service I'm currently building. Prior to this, most (all?) web service projects I had been involved in were based on SOAP.
REST is a heavily overloaded term in our industry, and can mean different things to different people. The author avoids that controversy by coining the term "Resource-Oriented Architecture", and shows different examples of web services that can be built using this approach: a social bookmarking service inspired by Delicious, and a mapping service. Both examples are RESTful but the author does an excellent job at showing why being RESTful is not enough. To fully leverage the existing web architecture (including the full HTTP protocol) you need, he argues, to do more than merely being RESTful, and he shows how.
The author never says so explicitly, but after reading this book I found that RESTful web services have at least two significant advantages over what the author coyly calls "Big Web Service" (aka SOAP):
1. Testability: do not underestimate the advantage of exposing a service that your testing team can test with cURL instead of having to setup a tool such as SOAPUI.
2. Discoverability: everything is a resource, and all resources will respond to a limited number of HTTP verbs. You don't have to worry whether adding a bookmark is done through `addBookmark()` or `appendBookmark()`; if your service is RESTful, you know that you need to send a POST to some URI.
The biggest takeaway from this book for me was to realise that it's possible to design an application where "everything is a resource", and that all resources respond to the same set of methods. Think of it for a moment. Will this not change the way you design non-web services too? Are not all your objects resources? Imagine, for a minute, if all your classes were restricted to expose not more than 5 public methods, and if these methods had the same names. It may sound crazy, but it's quite possible that you'd end up with a cleaner design built out of many small classes with small interfaces. Is this not an easy way to clean code?
What makes this book great and not merely good is that the author doesn't simply explain what RESTful web services are about. He is also clearly opinionated about it; however he is never patronising, never condescending. He takes very occasional jabs at systems he calls "Big Web Services" but never belittles them. His message comes across as entirely believable and convincing. By example after example he shows how popular services can be designed as collections of resources, and it is up to the intelligence of the reader to judge whether which kind of design is better.
REST is a heavily overloaded term in our industry, and can mean different things to different people. The author avoids that controversy by coining the term "Resource-Oriented Architecture", and shows different examples of web services that can be built using this approach: a social bookmarking service inspired by Delicious, and a mapping service. Both examples are RESTful but the author does an excellent job at showing why being RESTful is not enough. To fully leverage the existing web architecture (including the full HTTP protocol) you need, he argues, to do more than merely being RESTful, and he shows how.
The author never says so explicitly, but after reading this book I found that RESTful web services have at least two significant advantages over what the author coyly calls "Big Web Service" (aka SOAP):
1. Testability: do not underestimate the advantage of exposing a service that your testing team can test with cURL instead of having to setup a tool such as SOAPUI.
2. Discoverability: everything is a resource, and all resources will respond to a limited number of HTTP verbs. You don't have to worry whether adding a bookmark is done through `addBookmark()` or `appendBookmark()`; if your service is RESTful, you know that you need to send a POST to some URI.
The biggest takeaway from this book for me was to realise that it's possible to design an application where "everything is a resource", and that all resources respond to the same set of methods. Think of it for a moment. Will this not change the way you design non-web services too? Are not all your objects resources? Imagine, for a minute, if all your classes were restricted to expose not more than 5 public methods, and if these methods had the same names. It may sound crazy, but it's quite possible that you'd end up with a cleaner design built out of many small classes with small interfaces. Is this not an easy way to clean code?
What makes this book great and not merely good is that the author doesn't simply explain what RESTful web services are about. He is also clearly opinionated about it; however he is never patronising, never condescending. He takes very occasional jabs at systems he calls "Big Web Services" but never belittles them. His message comes across as entirely believable and convincing. By example after example he shows how popular services can be designed as collections of resources, and it is up to the intelligence of the reader to judge whether which kind of design is better.
August 29, 2014
Meh.
I really wanted to give the book a 2.5, but I gave it a 3 because of the Appendixes in the back of the book.
Granted I believe if I read the books when it was published (2008) or when i first bought it (2010-11 ) I probably would have given the book a 4.5.
I still would not have given the book a 5 because the author repeats himself a lot. He is even aware of it and points to multiple places in the book where he talked about the topic before, but that doesn't stop him from going over the topic again, in what is very close to full details, each time. This book could have been way shorter.
I bought the book when I was working on a RESTful service app with my supervisor at a previous job and saw that he was reading it. He is a really smart guy and I respected him, so I wanted to read it as well. He mentioned that he didn't really care for the book, but it did have a lot of good tips. The reason being, is that for a book that is about a particular subject, it reads more like a book on how to use Ruby for this particular subject. My supervisor was a senior Java programmer and since the book had heavy use of Ruby, it made it less desirable to read. This is one of the reasons why it took me so long to finish. Most of the subject matter in the book has now become common knowledge to most developers and because it was heavily focused on how to use Ruby to implement a RESTful service.
I really wanted to give the book a 2.5, but I gave it a 3 because of the Appendixes in the back of the book.
Granted I believe if I read the books when it was published (2008) or when i first bought it (2010-11 ) I probably would have given the book a 4.5.
I still would not have given the book a 5 because the author repeats himself a lot. He is even aware of it and points to multiple places in the book where he talked about the topic before, but that doesn't stop him from going over the topic again, in what is very close to full details, each time. This book could have been way shorter.
I bought the book when I was working on a RESTful service app with my supervisor at a previous job and saw that he was reading it. He is a really smart guy and I respected him, so I wanted to read it as well. He mentioned that he didn't really care for the book, but it did have a lot of good tips. The reason being, is that for a book that is about a particular subject, it reads more like a book on how to use Ruby for this particular subject. My supervisor was a senior Java programmer and since the book had heavy use of Ruby, it made it less desirable to read. This is one of the reasons why it took me so long to finish. Most of the subject matter in the book has now become common knowledge to most developers and because it was heavily focused on how to use Ruby to implement a RESTful service.
November 17, 2008
Overall, I really liked this book. It has gotten me excited about REST and Resource Oriented Architecture as a driving force for the programmatic web. I would recommend this book to anyone interested in learning about those topics.
On the other hand, I found the author's use of the first person "I" to be somewhat jarring, especially the fact that they repeatedly felt the need to re-emphasize that the information presented was "only their opinion and not hard and fast rules" relating to RESTful web development. Really, that kind of statement needs to be made once, in the Introduction or Preface, and then the whole book is covered.
I felt the book was organized in somewhat confusing way, as it started out with a number of client side programming examples and technology discussions before presenting an overview of RESTful principles. Also, the cover material implied that the examples were in Ruby & Python, when in fact the examples were almost exclusively in Ruby.
But aside from all that, it was a good read, well worth it.
On the other hand, I found the author's use of the first person "I" to be somewhat jarring, especially the fact that they repeatedly felt the need to re-emphasize that the information presented was "only their opinion and not hard and fast rules" relating to RESTful web development. Really, that kind of statement needs to be made once, in the Introduction or Preface, and then the whole book is covered.
I felt the book was organized in somewhat confusing way, as it started out with a number of client side programming examples and technology discussions before presenting an overview of RESTful principles. Also, the cover material implied that the examples were in Ruby & Python, when in fact the examples were almost exclusively in Ruby.
But aside from all that, it was a good read, well worth it.
March 25, 2008
REST REST REST. Everyone is talking about RESTful webservices, and there is some merit to the discussion. This was a very well thought out book and presented the REST topic in a sensible light. The only problem that I had was that the book could have been written in 200 pages, maximum. Aside from that, it is worth a read, especially if you want to learn more about REST and its philosophy. In a nutshell, REST involves taking a webservice that looks like
and changing it into something that looks like
There is a bit in between to get to this point, but it's not rocket science. Read the book.
-m
and changing it into something that looks like
There is a bit in between to get to this point, but it's not rocket science. Read the book.
-m
November 27, 2011
This book seems to be THE book to read if you want to really dig in to REST. I absolutely love the authors' Resource Oriented Architecture and how much their presenting it points to the abuse of the word "RESTful". However, I was disappointed in how one or two of their examples didn't quite meet all the criteria of ROA! With that said, I love theory and will undoubtedly continue to reference this book in my career.
If you want excellent commentary on Roy Fielding's dissertation and a step closer to a truly RESTful implementation, this is the place to go. If you just need to build a web service, just read up a bit on REST and go with it - but if you go that route, play it safe and avoid calling your service RESTful.
If you want excellent commentary on Roy Fielding's dissertation and a step closer to a truly RESTful implementation, this is the place to go. If you just need to build a web service, just read up a bit on REST and go with it - but if you go that route, play it safe and avoid calling your service RESTful.
January 17, 2016
Despite this book is old enough (about 10 years), it can be handbook when designing REST backend because describes all best practice to use REST in real applications. Which status code is most suitable in particular situation, how to design versionable services, url naming design, caching, access rights etc.
I can't say you can find something new in this book but this book will helps you to review your personal understanding of some parts to use them right. I found several places when I always made mistakes because my understanding was wrong. I will use this another way now.
I can't say you can find something new in this book but this book will helps you to review your personal understanding of some parts to use them right. I found several places when I always made mistakes because my understanding was wrong. I will use this another way now.
August 23, 2011
In my early days of web services, when Microsoft primarily focused on SOAP based WCF. Since, I was very much interested on REST concept, I bought this book. Leo and Ruby introduced me three things
1. Existing next generation web apps (Flickr, Amazon S3) and, new and simple way of key based authentication
2. ROA approach (in depth coverage)
3. The simplicity of Ruby language
The first three chapters forms the basis to the readers and chapter 4 explores ROA excellently.
1. Existing next generation web apps (Flickr, Amazon S3) and, new and simple way of key based authentication
2. ROA approach (in depth coverage)
3. The simplicity of Ruby language
The first three chapters forms the basis to the readers and chapter 4 explores ROA excellently.
August 11, 2013
nice book explaining the rest and roa. For rest-experienced programmers it can be little too long since it covers many side problems. I believe that sample code snippets could be also omitted and the book could easily fit in 200 pages.
nevertheless the book itself is written in simple and easy to understand language. if someone wants to learn or broaden his knowledge about rest t than it is a book worth recommending.
nevertheless the book itself is written in simple and easy to understand language. if someone wants to learn or broaden his knowledge about rest t than it is a book worth recommending.
November 27, 2015
A little lengthy with the code examples. I read this book mostly for the theory, which was good, but had to skip whole swaths of Rails code. If you are already familiar with Rails, I suggest you skip or skim those parts.
Otherwise, it was informative and still way ahead of it time in terms of real-world implementation.
Otherwise, it was informative and still way ahead of it time in terms of real-world implementation.
Read
February 4, 2016Would have really liked it .... if it was about 20 pages. I think the concept of RESTful web services is great, but did not need nearly 400 pages to drive this point home. If the author had just outlined what is considered a RESTful service and what it better than the RPC approach and left the rest to the appendices this would have been a four of five star rating.
October 29, 2007
not bad, but REST probably doesn't need a whole book. anything that has examples in 3+ languages is just trying to make a broad topic seem practical. nice coverage of what works and doesn't work, though, and general design suggsestions
September 11, 2009
I love restful web services. "The web as it should be used" is theoretically marvelous but practically difficult to do. This book will get you more excited about REST and help you a bit further but we still aren't there.
September 18, 2009
A different look at web/rest services than I've had before. I appreciated seeing the different side and there are definitely techniques I will take away, but I'm not sure I buy the authors arguments 100%.
January 7, 2011
This book is rather great. The concepts of RESTful architecture are very straightforward, and reading this book makes you realize that simplicity in integration and service calls brings simplicity and elegance to your systems design.
March 5, 2013
The best book I've read on the topic. This book is more about "what is REST and why" than "How to do REST". Having read this book, I know the philosophy behind REST, and can see my way through designing RESTfull APIs.
December 8, 2013
Эта книга является отличным источником информации на тему разработки RESTful веб сервисов. Но, на мой взляд, книга порою содержит слишком много несущественных деталей, ее можно было бы ужать как минимум на четверть без потери качества материала.
July 23, 2014
Not exactly a gripping read. I don't think it is clearly written, can be hard to see where things are going, found it repetitive and a bit long winded in places. Still, I guess it's a difficult topic to present and I'm learning things, in between being exasperated and bored, anyway.
November 22, 2008
Thorough and at times tedious look at REST-based services. It does cut through the hype and explain the benefits of REST rather well, though.
September 24, 2008
Makes up for what it lacks in quality with quantity.
August 25, 2008
Not sure I'll follow all of his suggestions, but definitely worth reading. I enjoyed the exposure to new concepts.
Displaying 1 - 30 of 48 reviews
Can't find what you're looking for?
Get help and learn more about the design.