thirdbIT

I have no recollection of how I ended up here:

On the REST front, if you’re claiming that it’s harder than the alternatives, to me that’s just a sign that you don’t understand it. Is REST simple? No, but neither is SOA. However, unlike SOA, which is fairly wishy-washy, noncommittal, and loose, REST’s constraints provide real, actual guidance for developers, and those same constraints also provide opportunities for significant flexibility, extensibility, performance, scalability, and serendipity. SOA’s contracts come with no rules or constraints, and thus can easily result in a system that’s extremely brittle, tightly-coupled, and virtually impossible to upgrade. SOA itself isn’t inherently bad, as it’s certainly a step above the “every application for itself” mode of development that’s so widely practiced. Unlike REST, though, SOA doesn’t go nearly far enough to provide real, useful guidance to the poor developer who has to actually write the stuff, make it work, and keep it running.

The author was responding to this guy:

This is the reason I am against dynamic languages and all of the fan-boy parts of IT. IT is no-longer a hackers paradise populated only by people with a background in Computer Science, it is a discipline for the masses and as such the IT technologies and standards that we adopt should recognise that stopping the majority doing something stupid is the goal, because the smart guys can always cope.

And that guy was responding, in turn, to this guy, who said that REST was like dynamic languages because both are loosey-goosey and flexible and don’t enforce contracts and type-checking.

The SOAP/WSDL/WS-* SOA view of the world is like a statically typed programming language, i.e. C++ or Java — everything is pre-defined, contracts govern everything, nobody can interact without following formal rules … and ideally, everything violating the rules (and policies) will get caught before even going into production.

So the chain is: 1) REST is very flexible compared to SOA, and that presents the danger that things that don’t work will be put into production. 2) REST is too complicated to be implemented by ordinary dumb programmers, and should be avoided. 3) REST is easier than than SOA because it provides very strict constraints.

So is REST easier or harder than SOA? Is it looser or stricter?

I just implemented my first REST API. I don’t see how anyone could say that it is ‘harder than the alternatives’, or that it doesn’t constrain developers very much. So I agree with the first quote, above. REST seems like a great idea to me. Anything that allows me to mostly avoid the complications of this many standards is good.

And also, obviously, I’m a big fan of dynamic languages now. I think I’d rather look at someone else’s crappy Ruby code than someone else’s crappy Java code, because at least there’s less of it. But I am, arguably, a Ruby fangirl right now, and given that I don’t have a CS degree, I guess I also count as one of the unwashed masses. And as a member of the masses, I can attest that no programming language in the world will stop us from doing something stupid. So we may as well enjoy ourselves while we’re doing it!

Last time I paid attention, XML-based web services were the next big thing. My informatics department was very cutting-edge, implementing web services for our apps to talk to one another and to our company’s intranet portal. XML was the big thing you had to know. It seemed enormously complex and confusing, and yet at the same time, simple. At the bottom, XML was data. People piled more and more stuff on top of the data, and made more and more tools to parse the XML that surrounded the data, and insulate us all from the XML, even though the whole point of XML was that it was supposed to be human-readable data.

It got to be that every single job posting you ever saw demanded that you be an expert in XML. This was ridiculous, since to the extent that XML is simply data it means nothing to be an expert in it, and to the extent that it was all the crap you threw on top of the data, it was impossible to be an expert, because even the experts weren’t experts.

Anyway, now all the cool kids are throwing XML out the window, and using JSON to send data back and forth to each other. JSON sounds incredibly dubious since it’s based on Javascript, and you all know what I think of *that*. But even javascript can’t quite manage to screw up the basic data structures, so maybe it’s fine. In addition to throwing XML out the window for data transfer and remote procedure calls between apps, the cool kids now hate it for configuration files (Rails people use YAML, for example.) And also, everyone’s web apps must be RESTful, a thing I don’t totally understand yet but which definitely means *hyperlinks should never, ever have side effects*.

The moral of this story is that by ignoring the world of software for a couple of years while being on the mommy-track, I have avoided, I hope, ever having to figure out what all those fifteen thousand XML standards meant, and jumping in now, I am no further behind on technology than all those other people who are still trying to grok what it means that Rails Edge now supports fully RESTful URL routing.