It’s rant time again (apologies – move along unless you’re feeling fiesty). It’s that REST vs. SOAP thing. There’s another round of debate traversing various blogs. This time it seems to be SOAP’s final death throes. If SOAP and all that makes little sense, know that you’re not alone and that you can happily ignore it and focus on smarter options.
Anyway, David summarizes from a distance while Tim Bray nailed the detail nicely a few weeks back in WS-Angst, which began with this post (which boils down to: “show me your data structures” vs. “show me your apis“) and finally ends up in this:
If you have Microsoft saying “well, the best approach is to make this elaborate infrastructure we’ve spent billions of dollars building out optional”, then the debate is over.
And make no mistake – it’s truly over. Forget whatever bizarre use cases WS-* support; when the real world starts doing this it’s time to move on. You want message routing? Try this…
< ?php $in = 'http://api.search.yahoo.com/WebSearchService'. '/V1/webSearch?appid=YahooDemo&results=10&output=php'. '&query=SOAP'; $data = unserialize(file_get_contents($in)); file_put_contents('/dev/null',serialize($data)); ?>
WS-Headless
On the one hand this is all forgivable human failing – too many architects spoil the WS-Broth. Design by committee means supporting strange edge cases and unnecessary complexity. Let’s move along to REST at last.
On the other, how about some accountability? Heads need to roll. This wasn’t just an amusing intellectual exercise to help boost flagging egos and payrolls – this was buzzed at high level and now real people are taking the flak when WS-projects fail, despite being dictated the choices leading to failure. The WS-Bandwagon is still in full steam even though the drivers have jumped clear.
At the very least, we need to prevent anything like this from happening again. Some ideas;
- If you employ architects, make them spend 4 out of 5 days writing code that someone actually has a use for. Programmers away from the keyboard get weird ideas – reality is a great reminder.
- If you’ve got a Great New Architecture, build a working prototype in Perl, before discussing it with anyone. You may use CPAN, which gives you a pretty good chance (call it learning from Roy).
- In describing your Great New Architecture, if you need to invent new words and acroynms, return to your keyboard.
- If you can’t clearly describe your Great New Architecture in under 60 seconds to a normal person, return to your keyboard. If you made them reach for a dictionary while doing so, please contribute 4 weeks voluntary service to a good cause.
- Do not, ever, form a committee.
- Do not invent use cases. If no one is doing it today, they won’t be doing it tomorrow either.
- Have at least two tales (from real experience) of how easy configuration, troubleshooting and debugging is. Better yet if you can produce the sysadmins you inflicted it on.
What remains now is to bring REST out of the WS-* debate and back down to earth, so we can solve the real problems of people using HTTP, like getting authentication working.
We also need to take note of what those doing real work are saying;
The best advice is just basically to keep everything as simple as possible—simple processes, simple SKUs, simple engineering. These systems get to be very big very fast. I don’t think there’s really any one particularly hard, gnarly problem, but when you add them all up, there are lots and lots of little problems. As long as you can keep each of those pieces simple, that seems to be the key. It’s more of a philosophy, I think, than anything else.
Harry FuecksHarry Fuecks is the Engineering Project Lead at Tamedia and formerly the Head of Engineering at Squirro. He is a data-driven facilitator, leader, coach and specializes in line management, hiring software engineers, analytics, mobile, and marketing. Harry also enjoys writing and you can read his articles on SitePoint and Medium.
