What is the Future of Web APIs?

Photo by Nicholas_T

APIs are about to enter a new phase, one where developers can easily program using multiple APIs at once, and non-developers can easily introduce API automation into both their business and personal worlds.  A time where APIs are seen as a valuable resource anyone can quickly put use, not just as a technical interface only the geekiest of us understand.

Web APIs have matured out of its earlier service oriented architecture (SOA) roots, often shedding a rigid SOAP approach to a more flexible RESTful implementation, increased efficiency by opting for more lightweight JSON over bloated XML, and becoming more accessible with API explorers and interactive documentation like Swagger, Mashery I/O Docs, and Apigee’s Console.

Now with over 6,000 public APIs available, there is a need to get more efficient about how we work with APIs, and evolve to where we can truly program the web.  But to get there, we have to add a new platform layer that can help standardize the authentication, interfaces and resource types available--simplifying how not just developers, but average users can take advantage of APIs.

One approach is targeting developers with new languages, or extensions of existing languages that can be used to program against one or many APIs, as with Webshell and Temboo:

	Webshell - A scripting language designed for fast API consumption and implementation
	Temboo - Platform allowing you to easily choreograph API workflows using Java, PHP, Python, or Ruby code snippets

The second approach is targeting a wider audience with automation platforms that create API driven tasks, such as IFTTT, Elastic.io and WhenAUser:

	IFTTT - IFTTT is a service that lets you create powerful connections with a simple If This Then That statement
	Elastic.io - elastic.io helps you to automate routine operations and connect multiple cloud APIs.
	WhenAUser - A simple rules engine that makes APIs tools work together

Both approaches provide a much needed platform to help make APIs more accessible, where one is still targeting the developer community and the other will allow anyone to take advantage of APIs through special automation tools and connectors. Beyond these programmatic and automation approaches there is a third approach to API usage, currently being defined to support mobile application development.  Companies like Cabana and Tiggzi are changing the way we build API driven mobile apps:

	Cabana - A visual way to build custom, API driven mobile applications
	Tiggzi - A GUI mobile application development platform

These GUI mobile application builders allow developers and non-developers to rapidly deploy mobile applications built on top of APIs, providing new ways of abstracting away the complexity of API integration we commonly experience today.  This approach to API bundling is also being put to use by Mobile Backend as a Service (MBaaS) providers like Kinvey, who are building in API gateways for common APIs that would be needed by mobile developers--a move we’ll see mimicked by other MBaaS providers.

Which of these three approaches reflect the future of the ProgrammableWeb?  Will it be an API programming language, an API automation platform, mobile back-end as a service or a blend of them all?

Only time will tell, but no matter which approach get us there, I can see we are getting closer to a truly ProgrammableWeb.

Tags: