SOA vs Mobile APIsSolution ·
I recently read an article from Bill Appleton of Dream Factory with the provocative title SOA is not a Mobile Backend.
It raised quite a few good points that were in the back of my mind for more than a year.
Basically, what is the difference between SOA and API?
To an extent it is largely the domain of the buzzword department but as you think about it, it is more profound.
SOA really is an Enterprise Creature. It’s a system integration strategy (despite what SOA purist will tell you). As Bill mentions in his article, SOA also typically comes with its heavy Enterprise artillery: Enterprise Service Bus, XML Message Translation, Service Locator, etc. . But it also comes with a set of useful practices: domain knowledge, reusable services, etc. .
API is an internet beast. How do you interact with a service on the cloud? You talk to its API. API are typically simpler in terms of protocols: HTTP, REST, JSON, simple messages, etc. . They are also messy: is an API about manipulating a specific entity or doing a consisting set of functionalities?
To me, they spawn from the same principles, i.e. standard interface to exchange information / commands in a loosely couple way between remote components. SOA is the Enterprise & earlier result of those principles. API is the internet / mobile later result.
SOA was tried by some big enterprises, forged by comity with expensive consultants and executives trying to solve the next 10 years problem.
API was put forward by a myriad of small companies and consumed by even more entities. They figured out the simplest way to expose / consume services quickly and learned from each other. In a few years a few set of practices were observed and documented and standards are even emerging.
Bill, in his article, contrasts the approaches in a way that reminds me of the old SOA debate of top-bottom vs bottom-top approaches, that is, do you discover your services by laying down your business processes and drilling down discover a need for services or by looking at your applications and which services they expose and hope that one day you can reuse them?
There is a lot of that in the issues brought by Bill around APIs. Like in SOA if you just spawn new APIs ‘On demand’, you’ll end up with a weird mosaic with overlapping concepts or functionalities. I agree that practices developed from SOA can definitely helped. Service Taxonomy, for instance, forces you to think of how your services will align and where their boundaries will be drawn before you start.
But for an organization, I believe it is nearly a forced therapy to implement one or two APIs, experiment them in full operation before you can start having serious discussion around other SOA aspects. Once you’ve tried it, you can have a much more informed discussion about what changes and at which in a service (while discussing versioning), what type of security rules make sense and a bunch of other aspects.
Otherwise you fall victim of the good old analysis paralysis and will host meetings after meetings for deciding about something because everyone has a different a priori perspective on it.
So my suggestion is yes, API are a little messier, but experimenting with them, even if you end up with a lot of rework, will bring much value to your organization. So go, and create simple API, expose them and operate them!