Posted on 08-07-2014
|Daniel Jacobson - Scaling the Netflix API|
I was learning more about the discovery of private APIs with the Charles App, and was fascinated by its potential to visualize, and map the darkest regions of the API realm. There is a lot of speculation about the number of APIs out there, with the 10K+ public APIs that are currently available being the “tip of the iceberg”, and the number of private APIs rpresenting the rest of the surface area below the dark surface--making the approach that Tim Rogers (and others) employ a tantalizing option for mapping these dark waters of the rapidly expanding API space.
HTTP proxing and monitoring solutions like Charles are nothing new, and there are a wealth of next generation API integration tools like Runscope and APITools available, but what is interesting about this, is the routing all of your app traffic for your laptop, tablet or smartphone through a proxy, and record not just the traffic between you and the private APIs your apps depend on, but the mapping out the API interface, request, response, and underlying data models.
Before I continue with this story, I have to admit this is a little on the dark side of APIs, and is something I don't recommend doing, because you are going to piss off a whole bunch of API providers—regardless, I think it is an interesting idea, that is worth sharing and discussing.
What if someone packaged up an HTTP proxy, monitoring, and provided a recording layer for the interface, requests, responses, and data models, scrubbed out PII, and allowed individuals to opt in and publish the resulting definitions to a shared, public registry?
Of course you would not publish your own transmissions, and underlying data, you would only publish the interface, requests, responses, and data models for the private APIs that are driving your public mobile and tablet applications. This centralized location would then aggregate, and shed light on this dark region, providing a single directory to discover what goes into all of the private APIs we depend on in our everyday lives.
Something like this would pretty quickly map the world of private APIs, but at first glance I think the negative backlash would far outweigh the benefits. Mobile app providers would recoil, and probably look for ways to secure the inner workings of their mobile apps...or would they? It might also have the opposite effect, and push providers to realize they need to be more transparent with their APIs, and while they don't need to open up access to for everyone to use, they could publicly share the technological surface area their(our) apps depend on—which in my opinion is never the secret sauce, and a company should always be willing to share. (I know controversial) Think of it as the shared zone between provider and app.
The concept of a rogue API registry for internal APIs is one of those areas I see as pretty damn grey, and I'm unsure how I feel about it. I personally wouldn't recommend building a tool or a registry for mapping private APIs like this, because I worry about the repercussions it would have. One the other side it also fascinates me, and is a concept that is very much in the public domain already, and is something I feel is worthy of discussion, or at least more thought.
comments powered by Disqus
Winning in the API Economy
|Download as PDF|
Latest Blog Posts
- Where Do We Start With APIs At The University of Oklahoma?
- What I Would Look For When Hiring a Modern API Developer?
- The U.S. International Trade Commission Includes APIs In Latest Report
- Thank You @3Scale For Investing In The Community With @APIStrat
- Introducing API.Report, A Community API News Site
- Extract Knowledge From Audio And Video Using The Clarify API
- My API 101 Workshop At @APIStrat In Chicago Next Week
- Some Advice For The Enterprise When Beginning Your API Journey
- Machine Readable API Definition Format Swagger Matures to 2.0
- How Do We Continue Moving Green Button Data And APIs Forward?
- Beyond Public APIs In Government: Internal Access to Resources
- Can You Show Me The ROI On All Of This API Stuff Before We Commit
- In The Future APIs Will Be Default For All Cities
- No Public APIs Are Not Going Away Just Cause A Few BigCos Fumble At It
- Internal API Search Engine For Everyone At Your Company (Not Just Developers)
- If You Need Assistance With Your Healthcare API Strategy I Have The Person
- Explaining APIs To Senior Leadership: Access To Company Resources Without The IT Hassle
- A Conversation With @ijroth, @dorkitude, @antonyfalco, and @medjawii In The Next Generation API Stack Panel @APIStrat
- API Evangelist Thoughts On The Right To An API Key And Algorithmic Organizing
- Explaining APIs To Your Senior Leadership
- An API Evangelism Strategy To Map The Global Family Tree
- Thank You For Your API Evangelist Blog(s)
- Video From The Hypermedia Panel At API-Craft In Detroit Last Month
- Please Open Source Your API Before Shutting It Down
- Explaining My Work Around APIs In Higher Education To Institutions