Pop.co explains why they went to an API-first development model.
This is going to be a continuing trend. More and more places are already doing this, even if they’re not blogging or talking about it. With the continued growth of mobile devices, to become co-equal with a website, if not the predominant way that people interact with companies, there is an imperative to go to APIs first.
Why?
- Consistency is key. Companies will want to deliver the same or comparable capabilities, to the extent possible, across websites and mobile apps. There’s obvious duplication. Rather than duplicate efforts, APIs allow companies to reap economies of scale across the two platforms. One API can support both. New features can be released to both simultaneously using the same service-layer infrastructure.
- Agile is not pure hype. This is how smart software developers work. And APIs are designed for Agile philosophy. APIs get versioned and updated rapidly. There’s no rigid, fixed schema, no “WSDL” to update and fiddle with. Think about it – that is just a clean restatement of the “minimal docs” plank of the Agile philosophy. If you’re agile, you want APIs. They support your work rather than fight it.
Everyone is going to be doing this.
I don’t agree with everything in that POP.co post. For example, POP lists “Scalability” as a reason for going to APIs. I don’t see it. Their theory is that Separation of concerns leads to scalability, meaning they can have web servers and API servers and scale them independently. But Microsoft refuted this as a requirement for high performance long ago. ASPNET proved that you can build a stateless layer of web/app servers, backed by a fast datastore layer, that screams. There’s no real performance benefit to separating the HTML server from the “API Server”.
On the other hand, the other reasons that POP.co offers for going to APIs first, make a ton of sense to me.