“What’s the difference between APIs and SOA?” A question with a million answers.
I’m not going to tell you I’m the holder of the One True Way here. I’m going to give you the Smart421 position.
To us, SOA was always about delivering easy to understand interfaces that expose business functionality from diverse underlying systems. We always felt this was as much about people as technology, and we never particularly bought into all the vendor hype that demanded true SOA required a massive stack of complicated tools and technologies, that (what a co-incidence!) only Vendor X could provide.
We’re simple straightforward folk, who like simple straightforward solutions.
Let’s take registries and repositories as an example. I once said to a colleague that one vendor’s product looked like it was designed by machines, for machines. It used language like Port Types, Bindings, Metadata, Ontologies etc. It was the dream of people who like to put acronyms on their CVs. What it didn’t help with at all from what I could see is helping the developers throughout your organisation discover services, and really understand quickly and easily what the service did, and how to use it.
The API movement has, by necessity, stripped a lot of the complexity away. Why? Because it turns out that if you are going to expose APIs to the outside world, where people have a choice about whether they should use your API or someone else’s, ease of use, and ease of discovery are critically important characteristics. Integrating with a REST(ish) API is, frankly, easier than integrating with a SOAP service. Discovering services and understanding them on a developer portal that is designed for humans is easier than poring over piles of WSDL in a freakishly complicated registry product.
If you’ve wondered why truly successful SOA initiatives are common as unicorns, here’s why: They often overcomplicate everything. Technology, processes, standards and the services themselves become a barrier to the very innovation they set out to enable.
Of course, nobody mandated SOAs have to be complicated. Nobody forced the world to adopt WS-*. We often tried to encourage customers to delay adopting complexity until the last responsible moment. That’s not to say WS-* weren’t useful. In the right contexts, they were, but they often came at the expense of accessibility and increased friction in adoption.
Unfortunately, the brutal reality is that for most people (or at least those who commission such initiatives), SOA as a term is connected indelibly with SOAP, ESBs, WS-* and rigid over-engineered change processes.
Sometimes, beautiful relationships don’t work out. Sometimes you just have to move on. So we have.
For us, APIs are the new SOA. What you might call SOA, we will refer to simply as internal APIs. On one level, this doesn’t change anything – it’s an emphasis thing. We still believe in the principles that underly SOA, and we’ll continue to build our integration on this basis. We know that APIs aren’t a silver bullet either. We’re certainly not saying “As long as it’s an API it’s good, and any old API will do”. There’s still plenty of scope to fail, plenty of mistakes to make (and to avoid repeating), and plenty of learning to do for our customers, for us, and for the entire API ecosystem.
But whether internal or external, we’ll focus on the same thing: Crafting APIs that are beautifully easy to understand, consume and change. We’ll fight the good fight to keep the standards and technologies we use mercifully simple, lest APIs suffer the same fate as SOA. We’ll try wherever possible to make the technology fade into the background.
“A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”
– Antoine de Saint-Exupéry
Share this post using the social icons below or via the short URL http://bit.ly/1ekeVNy
Please Rate and Like this Blog. Our Readers want to know what YOU think so please Comment.