Building APIs You Won't Hate: Review

Originally published at: http://www.sitepoint.com/build-apis-wont-hate-review/

This is a review of Phil Sturgeon’s book Build APIs You Won’t Hate.

Build APIs You Won’t Hate

A bit of an edgy title, isn’t it? It makes sense, though. The potential of a developer hating anything he built given enough time to work on it is enormous. It’s an inverse parabola of sorts – your enthusiasm will grow for a given amount of time, and then proportionally drop until you sink below the starting point of pleasure. If you push through this depression, learn new techniques, and then apply them to your work you get a kind of sine wave in which your enthusiasm again rises until it starts dropping, and so on and so forth.

Continue reading this article on SitePoint
1 Like

Very good book indeed. I used it a lot as a reference for building our API.

1 Like

apOStrophical (as in apOStrophe) not apSOtrophical.

If you’re going to criticise somebody else’s spelling, you should at least double check your own! If the spell checker doesn’t pick it up, you should eyeball it!

Thank you Bruno!

You’ve given me some great feedback. I’ve fixed those pro’s and con’s and a few other bits. I have had multiple technical editors go through this stuff, but certainly need to get a proper editor on the case. I’m doing that now.

Last year I was too busy being internationally homeless and broke to concern myself with such things, but now I’m back to work and stable I can certainly part with a little cash to get this book to the best quality it can be.

Thanks again!

Doh! Thanks, fixed.

You’re welcome - thanks for a great book.

I’d recommend opening a public repo for typo submissions and other issues like Brandon Savage did for his book. I spammed that repo with some 20 issues while I was reading, it was simple to have it open in another screen and just put the encountered errors there. In most cases, people won’t bother to tell you about a mistake because it’s minor (who really cares about “pro’s” vs “pros”? - we all know what is meant by it), doesn’t reduce the content’s value, and - perhaps most importantly - because it’s tedious to break the reading flow just to report a typo or make a note of where it was. People like me don’t mind, we’re trained to break flow to shoot lightning, but others may mind. Having an easy to access repo might take care of that last point for them. This would also make it easier to have multiple pairs of eyes go through it, rather than just hiring a solo editor, though doing both is probably the optimal approach.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.