Startups Need To Work Together on API Definitions
02 May 2013
I am tracking on 2000 APIs that I have deemed worthy enough to pay attention, out of the 9000 on ProgrammableWeb, 13,000 in APIHub and numerous APIs in Mashape's marketplace. In addition to these APIs, I'm also closely watching 30+ backend as a service providers, 20+ reciprocity providers and emerging big data, analysis, visualization and other emerging platforms who are using APIs in new ways.
I was reading some of the great research coming out of OPENi, which is a "Open-Source, Web-Based, Framework for Integrating Applications with Cloud-based Services and Personal Cloudlets"--specifically the post on OpenI API Framework: Studying the Landscape of Cloud-Based Services.
What is great about OPENi, is they are doing all this research and planning, and sharing the process with everyone publicly. Which is great for everyone, but will take some time to play out, as they study, plan and execute in the space.
As I watch aggregate API providers like Singly plow forward and reciprocity providers like Zapier deliver some amazing integrations, using APIs, and bridging some of the most meaningful cloud platforms in our world--I can't help but think about how much redundant work is going on amongst startups.
When it comes to the definitions of specific APIs, the nuances of their interface and authentication, each of these service providers is doing their own work, in a silo. In a perfect world, API providers would provide Swagger definitions, standard oAuth implementations, etc. API owners would do a lot of the legwork for these providers. As we know, this isn't the reality, and each of these aggegrators, reciprocity providers, analytics tools are all mapping these API connections on their own.
I can't help but think about, how if providers stepped up, communicated with each other, they could establish some sort of commons for all of these API definitions to reside. They could colloaborately develop a way they could identify the meaningful APIs, hang Swagger definitions and code for connecting and authenticating in a multitude of programming languages.
Each provider could still maintain their secret sauce, what happens before and after each API connection, allowing them to have their own unique approach to API aggregation, reciprocity, analysis, visualization or real-time tools. But by sharing the API definitions and working together on the connections, they could spend more time on what makes their companies unique, rather than hand-rolling each API connection in isolation.
Just some random thoughts, as I navigate the world of APIs, from within my own silo!