Let’s begin with the great sides:
- As I discussed above, the construction of every chapter devoted to a design sample is repetitive. It makes the chapter simple to devour, as you recognize precisely what to anticipate.
- Usually, I learn my technical books simply earlier than going to sleep as a result of I’m fairly busy in the course of the day. Most books have lengthy chapters, requiring me to cease mid-chapter after I begin to go to sleep. If you begin once more, you could get again a number of pages to get the context again. The size of a chapter of API Design Patterns is right: neither too lengthy nor too brief.
- The Design ideas part begins from the fundamentals. You don’t must be an skilled on API to learn from the e-book. I used to be not; I hope that I’m extra seasoned by now.
- I used to be a bit doubtful at first concerning the Workout routines part of every chapter, for it didn’t present any answer. Nevertheless, I got here to appreciate it prompts the lively recall mechanism: as an alternative of passively studying, actively recall what you realized in answering questions. It improves the memorization of what was realized. As a further profit, you possibly can study in a gaggle, examine your solutions and finally debate them.
Now, I’ve some critics as properly: * Some patterns are immediately taken from Google’s API Enchancment Proposals. It’s not an issue per se, however when it’s the case, there’s no dialogue in any respect about potential alternate options. For instance, the chapter on customized strategies describes tips on how to deal with actions that don’t map exactly to an HTTP verb: a financial institution switch is such an motion as a result of it adjustments two assets, the “from” and the “to” accounts.
+ The proposed Google AIP is for the HTTP URI to make use of a : character adopted by the customized verb, e.g., /accounts/123:switch. That’s an thrilling proposal that solves the dearth of mapping subject. However there aren’t any proposed alternate options nor any motivation for why it needs to be this fashion. As an engineer, I can hardly settle for implementing an answer with such far-reaching penalties with out being supplied with different alternate options with their execs and cons. * Final however not least, the e-book doesn’t point out any related RFC or IETF draft. Chapter 26 describes tips on how to handle request deduplication, the truth that one could must ship the identical non-idempotent request repeatedly with out being afraid of ailing unwanted effects. The proposed answer is nice: the consumer ought to use a singular key, and if the server will get the identical key once more, it ought to discard the request.
+ It’s exactly what the IETF draft describes: The Idempotency-Key HTTP Header Area. Nonetheless, there’s no point out of this draft, giving the sensation that the e-book is disconnected from its ecosystem.
