Posted on 05-02-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!
comments powered by Disqus
Winning in the API Economy
|Download as PDF|
Latest Blog Posts
- Top 5 Most Popular Themes On API Evangelist In 2014
- Query Parameter Determining Which Fields Are Queried For API Call
- Now Our Development Environment Is Now Containerized And Scalable Like Our Production Environment
- Guest Post: Let Our Sponsors Blow A Little Smoke Up Your Ass
- API Discovery Continues Its Move Into The IDE With Eclipse Che
- Evolving Beyond Just Resources Towards A More Experience Based API Design
- Another View of The API vs. Data Download Model
- If You Have A Publicly Available Mobile App You Have a Public API
- Reducing The API Stack Down From 830 to 690
- Gathering My Thoughts Around Common Patterns For Base URLs Across Nearly 700 APIs