Rise of the API and the Trouble Ahead
In the late 90’s, I was deep into transactional systems and enterprise integration projects. The tools for such work were rather complex and involved things like CORBA, IIOP and RPC. The messaging deliverability infrastructures like MQ. transaction monitor such as Tuxedo or application middlewares like Weblogic and Websphere underpinned mission-critical systems.
Building applications on these architectures was an incredible chore. The process required writing significant amounts of low-level code to optimize speed and resiliency while talking across operating systems, hardware, networking protocols and databases. Decoupling client/server code into separate interface, business object and database code took a ton of time and great care. In a nutshell, it sucked.
Fast forward a decade later, and the whole paradigm of integrating systems has been completely upended. Within a weekend, a talented programmer can build a mash up of content across a host of popular web services such as Facebook and Netflix and Twitter and Foursquare. There are “big data” companies that are offering API’s to access data to enrich applications. A whole community of API management vendors like Mashery and Apigee have sprouted up to help web companies manage and monetize their API’s. Even local, state and federal governments have gotten into the game. All told, according to ProgrammableWeb, there are over 3,000 available API’s to access today, and that number continues to grow at a healthy clip.
We are now living in the era of the democratized web. The success of early Web 2.0 companies and the rise of expansive platforms such as Facebook and Twitter has spurred the dreams of would be Internet moguls. The ease and cost of developing useful web and mobile applications coupled with the availability of online resources has created a class of DIY, self-taught hackers. In the rush to build the next big thing however, we are seeing a rash of applications that are unstable and insecure and difficult to manage.
We now have the opposite problem; in making it easy to build applications and integrate various API’s, we have lost touch with the fundamentals. This has introduced significant risks to users and made the life of developers much more difficult, particularly when it comes to managing all of the changes across API’s they are using. With more applications being released at an exponential rate by Internet and mobile entrepreneurs, web design and development agencies, universities, corporations and government departments, these problems are only going to get bigger and uglier. It pays to remember that with great API power comes great API responsibility.
We need better tools to help the consumption side of API’s and make the management and usage of API’s easier for developers. That is why I am excited about tools like Trove* that can help to significantly reduce the overhead for developers building applications that heavily leverage user content. I believe this is an area that is only going to grow over time, much like the market for services developed on the API provider side. We have already seen this model garner success with the rise of companies like Twilio that have democratized the building of telephony applications or Embedly that allowed an easy way to convert URL’s to rich content. With the options and availability of API’s expanding, there is a huge opportunity ahead to serve the needs for the consumers of API’s.
If you are interested in seeing this technology in action, I invite you to join the Trove NYC Meetup and Hack Day this coming Sunday at WeWork Soho. The event is free to join and will include developers from some of the top web companies in NYC, hacking away to build awesome mashups accessing multiple API’s through Trove. Even if you cannot join us, keep an eye out on this space as it is going to heat up over the next 12 months.
*Note that I am an advisor to Trove.
15 Notes/ Hide
- david-noel liked this
- marksbirch posted this