This is incredibly interesting. According to some people we're looking at unprecedented growth in the space. Right now there's roughly 9k public APIs. By 2019 that number could be over 100,000.
The question becomes though who does the integrations? Not everyone is a developer. The world needs plumbers for toilets and electricians for lights. I think the future of web development looks a lot like these industries. If a website is a house you'll hire a general contractor who will outsource to various experts in various APIs. At least that's our take on it.
> The question becomes though who does the integrations? Not everyone is a developer. The world needs plumbers for toilets and electricians for lights. I think the future of web development looks a lot like these industries. If a website is a house you'll hire a general contractor who will outsource to various experts in various APIs. At least that's our take on it.
I certainly believe that in some cases, companies will take advantage of APIs directly. In many others, however, I think you're more likely to see new businesses built on top of APIs. These businesses will develop the applications that companies use.
A key thing to consider is that a lot of functions that the new breed of API providers seek to provide are currently bundled with other products/services that customers don't necessarily need.
Example: Company A might be spending $xxx/month for a service that provides X, Y and Z when it only really values Z. If an API provider can aggregate enough demand around function Z so that third parties can cost-effectively build offerings around function Z only, Company A may now have the ability to find a service that meets its needs at a lower cost.
So while I'm sure there's going to be a healthy market for developers focused on API integration, I think the bigger opportunities are around taking advantage of these APIs to create more focused, cost-effective solutions. Think of it as the software industry's equivalent of "unbundling."
I think the answer to that lies in HTTP discovery protocols. I'm imagining self-organizing applications based on the need of the user, wiring together representations of disparate data sources into a cohesive interface.
You shouldn't have to be a dev to take advantage of the API universe. You'll just need tools that are able to reason about the data available.
That's the goal of the semantic web/linked data, and it already works for simple cases. But to take advantage of that you can't be stuck in the popular "REST-but-not-really" custom APIs; you need standard formats and protocols (e.g. RDF/a and SPARQL) that can be queried by software that knows nothing about that particular service.
The question becomes though who does the integrations? Not everyone is a developer. The world needs plumbers for toilets and electricians for lights. I think the future of web development looks a lot like these industries. If a website is a house you'll hire a general contractor who will outsource to various experts in various APIs. At least that's our take on it.