Take a photo of a barcode or cover
3.01 AVERAGE
3.01 AVERAGE
informative
medium-paced
As much as the other reviews say that the handmade format the author want to get us to eat by force the gold nuggets you can find mixed with those parts is just worth getting this book for.
I may not have that much amount of experience to say exactly "this in practice is bad" but let me tell you that having the same mindset the author has when designing api's is pretty interesting and the changes that asks for are not that big and for beginners this is not a bad starting point, just take the parts that make the api more usable because the format is not even used outside of this book, it's like a software engineer with years of experience that feels frustrated about never releasing something used by other developers and pulling it out of his ass whenever he talks about his experience so it doesn't sound like he feels better about himself.
I may not have that much amount of experience to say exactly "this in practice is bad" but let me tell you that having the same mindset the author has when designing api's is pretty interesting and the changes that asks for are not that big and for beginners this is not a bad starting point, just take the parts that make the api more usable because the format is not even used outside of this book, it's like a software engineer with years of experience that feels frustrated about never releasing something used by other developers and pulling it out of his ass whenever he talks about his experience so it doesn't sound like he feels better about himself.
fast-paced
Good book. Although it's old. Probably this book should get a new edition.
If you're new to the world of REST APIs, and if you're looking for a good set of working rules on how to design them, then Mark Massé's REST API Design Rulebook should live up to its title just fine. It's a short book (you could read it in an afternoon) and it tackles the subject matter in a direct and orderly fashion. It starts with a brief history lesson, quickly reviewing the history of the world wide web, of HTTP, and of the emergence of the whole notion of "RESTful" APIs and services. From there, he lays out the six constraints of the web's architectural style, [1] and how RESTful designs fit into that. The rest of the book is basically just a series of "rules" to follow when designing a REST API, along with use-cases, examples, and justifications for each of those rules. Many of these rules seem very common sense and sound a lot like every other bit of advice you've ever received about (for example) naming variables and methods; [2] other rules seem sensible but get boxed in by "real-world" difficulties [3] or else seem counter to the prevailing wisdom; [4] still others seem to be little more than evangelizing for Massé's own proposed WRML design/modeling framework.
For me, the highlight reel included: the first three chapters (on identifier design, interaction design, and metadata design), and some of the discussion in the final chapter ("Client Concerns") about security, and the overview (however brief) of JSONP and CORS as solutions for some otherwise challenging situations.
The two bits where it went off the rails a bit for me: (1) Any of the discussion of "hypermedia" and/or between-document linking--I haven't encountered this much (at all?) in the real-world and a lot of it seemed overkill to me, to go into that depth on how to link documents from within the API. [5] (2) WRML: what? Even after reading the whole book, I was still left wondering what exactly WRML was intended for, and what it would buy me as a developer. It seems that Massé wrote this book in part to evangelize this framework, but I could not quite get my mind sufficiently around it to say that I got it.
On the other hand, Massé does a great job with the "rules" (again: especially in the first half of the book) and I would recommend this to anyone that needs an introduction to REST API design. That being said, after absorbing this one, you'll probably want to explore further with one of the other O'Reilly books on the subject, and/or find yourself a couple of resources on OAuth.
(Disclosure: I received an electronic copy of this book from the publisher in exchange for writing this review.)
----
[1] (1) Client-server; (2) uniform interface; (3) layered system; (4) cache; (5) stateless; and (6) code-on-demand.
[2] E.g., use singular nouns for documents; use plural nouns for collections and stores; use verbs ("and verb phrases") for actions, etc.
[3] In Chapter 2 ("Interaction Design with HTTP") Massé advises you to use the pedantically correct HTTP methods for performing the corresponding actions: e.g., if you want to delete a document, send a DELETE request to the document's URI. However, as most web developers already know, mainstream browsers will not respect any HTTP methods other than GET or POST--so you can forget trying to use PUT or DELETE as a form's method, and you're stuck using POST as a wrapper. (Here is a good Stack Overflow thread on the subject.)
[4] E.g., all those API URIs that have a '/v1/' in there somewhere? to specify the API version? Massé says: "Don't do that."
[5] And as an aside, it was very unclear to me how the rel (relationship) attributes were even suposed to be defined. Some central standard? Part of WRML? Do you make stuff up and furnish an end-point in your RESTful API to explain the rels?
For me, the highlight reel included: the first three chapters (on identifier design, interaction design, and metadata design), and some of the discussion in the final chapter ("Client Concerns") about security, and the overview (however brief) of JSONP and CORS as solutions for some otherwise challenging situations.
The two bits where it went off the rails a bit for me: (1) Any of the discussion of "hypermedia" and/or between-document linking--I haven't encountered this much (at all?) in the real-world and a lot of it seemed overkill to me, to go into that depth on how to link documents from within the API. [5] (2) WRML: what? Even after reading the whole book, I was still left wondering what exactly WRML was intended for, and what it would buy me as a developer. It seems that Massé wrote this book in part to evangelize this framework, but I could not quite get my mind sufficiently around it to say that I got it.
On the other hand, Massé does a great job with the "rules" (again: especially in the first half of the book) and I would recommend this to anyone that needs an introduction to REST API design. That being said, after absorbing this one, you'll probably want to explore further with one of the other O'Reilly books on the subject, and/or find yourself a couple of resources on OAuth.
(Disclosure: I received an electronic copy of this book from the publisher in exchange for writing this review.)
----
[1] (1) Client-server; (2) uniform interface; (3) layered system; (4) cache; (5) stateless; and (6) code-on-demand.
[2] E.g., use singular nouns for documents; use plural nouns for collections and stores; use verbs ("and verb phrases") for actions, etc.
[3] In Chapter 2 ("Interaction Design with HTTP") Massé advises you to use the pedantically correct HTTP methods for performing the corresponding actions: e.g., if you want to delete a document, send a DELETE request to the document's URI. However, as most web developers already know, mainstream browsers will not respect any HTTP methods other than GET or POST--so you can forget trying to use PUT or DELETE as a form's method, and you're stuck using POST as a wrapper. (Here is a good Stack Overflow thread on the subject.)
[4] E.g., all those API URIs that have a '/v1/' in there somewhere? to specify the API version? Massé says: "Don't do that."
[5] And as an aside, it was very unclear to me how the rel (relationship) attributes were even suposed to be defined. Some central standard? Part of WRML? Do you make stuff up and furnish an end-point in your RESTful API to explain the rels?
Nice thoughts, but feels like an academic paper out of touch with modern dev.
informative
Somehow useful... There is a nice description about the types, controllers, methods, but I want more...
The authors concept of WMRL is too complex.
The authors concept of WMRL is too complex.
I've seen other reviews comment that this book is great if used as a reference, but strange if you read it straight through, as I did. Since it is a rather short book, I ponied up to the so called bar and went for it.
There are definite things to think about when design a REST API, but most cases the user will be using a framework such as Express of ASP.NET which will do a lot of the heavy lifting for you.
I'll keep a link to the ebook handy in case I have questions going forward, as a reference is the best way to use this book, not necessarily as a set of rules that must be followed explicitly.
There are definite things to think about when design a REST API, but most cases the user will be using a framework such as Express of ASP.NET which will do a lot of the heavy lifting for you.
I'll keep a link to the ebook handy in case I have questions going forward, as a reference is the best way to use this book, not necessarily as a set of rules that must be followed explicitly.
A quick and somewhat interesting read. Half of the book contains good guidelines to follow when designing REST APIs, the other half is an ad for author's WRML format that didn't end up getting much traction (which makes the read quicker and less interesting).