REST API Notes for 2018-12-14
At the end of last year, Pakal De Bonchamp published an article, "REST is the new SOAP". I see a fair amount of these hamfisted takedowns with click-baity titles when scouring the web. The approach I've adopted is, largely, to ignore them. While there might be truth, if it is overshadowed by the personal axe the author wishes to grind then there are better uses of my (and, by extension, your) time. Whatever insight might be had does not outweigh the cost to comprehension (or good humor).
I'm making an exception for Pakal's article, the rollicking blaze of lit straw men that it might be. The condemnation was swift and contained a tremendous amount of valuable insight. It would be unfair to point out all the tremendously good reaction without acknowledging the original catalyst.
Mark Little, writing for InfoQ, has an exceptional recap of the original piece, along with the most salient responses. The pièce de résistance is Phil Sturgeon's "A Response to REST is the new SOAP". The careful comparison and contrast is illuminating:
"I get it, REST is a complex topic. Too many people think they understand it, and are falsely validated when they bump into other people who don't understand it. Folks everywhere are building RESTish APIs which are basically just RPC + HTTP verbs + Pretty URLs, and as that doesn't seem very helpful they write giant articles explaining why that's not very useful…"
Amen.
SURVIVING MICROSERVICES
I talked about how we will see a microservices counternarrative in my 2018 outlook. In short, the stories of complexity and cargo culting gone wrong will come to the fore.
Case in point is Michele Leroux Bustamante's presentation, "Surviving Microservices". Michele's slides do an excellent job of conveying some of the problems inherent with the pattern, even without the audio. Recommended for anyone wishing to go into microservices development with the full picture of the cost/benefit ratio.
A MATHEMATICAL APPROACH TO QUANTIFYING THE COST OF VERSIONING
The piece, "Understanding the Costs of Versioning an API", is older. However, despite being written in 2013, it holds up as a fascinating look at versioning.
I acknowledge that a versioning strategy is important for an API design. To not have a strategy for accommodating change is to embrace eventual obsolescence with a big, wet smooch. But, versioning an API should be a rare occurrence, avoided in all but the most extreme situations. This piece does a great job of illustrating why.
MILESTONES
- I was excited to see Arnaud Lauret is writing a book for Manning. Entitled "Everyday APIs", the first two chapters are now available. Further, if you use the code "mllauret" to pre-order, you get 50% off the finished product.
- XML has turned 20. Tim Bray, writing on XML.com, briefly, looks back on the 20 years since the February, 10th release of XML 1.0. While any web API practitioner works almost exclusively in JSON, it is worth noting all the various situations were XML are still used.
WRAPPING UP
There have been a handful of additions to webapi.events. Give it a quick glance if you're looking for a community to discuss the latest and greatest face-to-face. Is it something missing? Either respond to this note directly or send me an email at 'hello@matthewreinbold.com'.
Next week I'll be out in sunny San Francisco. More to come soon.
Til next time,
Matthew