The API wars are coming
gigaom.com
gigaom.com
The big problem with the micro-API paradigm is the lack of standard. Sure, they might all use REST, but the semantics of the data is highly arbitrary. Take 10 very similar web services with REST APIs, you'll quickly realize that they're all completely different and that you have to learn how to use them one by one. The solution to this is to standarize data, and I believe that the semantic web and linked data is a much superior approach.
If we all built our APIs with a registered content type, it would really go a long way for standardizing APIs. Throw in some HATEOAS and you've got standards and links.
There's no reason why I shouldn't be able to select an existing data model (from some popular source, or microformats), and generate a REST endpoint in 1 click. There's no reason for anyone to manually create local classes that mimic these models, code the logic that convert the models in and out, and do a bunch of other manipulations using installed libraries. I just want to select the data, plug it through third-party libraries as a service (online APIs/functions, some of which being open source could be cached locally within the code), and be done with it.
We need to be able to reuse everything in a seamless way. Currently, reusing something often means more work and frustration, and most people end up coding their own lesser clones/forks that "does the job". Sigh.
REST is an architecture that can be implemented in many different ways, so I doubt there will ever be a one size fits all for REST. I think the real win will be when web frameworks allow us to work primarily with resources and representations instead of an MVC architecture.
They share the same medium, but they don't share the semantics. Learning standard English is an effort we make to communicate more effectively, and I strongly believe that software should do the same thing with data.
Just take a look at how software is done. The first step of many project is to define classes, to reinvent the definition of extremely common entities. Why exactly do we need 10000 different classes to represent a "Customer"? Why can't multiple projects share the same "User", "Product", "Student", "Location" and "Transaction" classes? Not only would I not have to reinvent a lesser wheel, but I wouldn't have to explicitly explain how my definition of a "Customer" relates to your definition of a customer. We're just starting to reuse code, thanks to libraries. Why can't we do the same with data models?
Now, some might say that their version of a model is better than the standard one. If that's the case, then it would be selfish not to share this improvement with the world, and prevent others from benefiting from this improvement. Simply update the model, and the changes are applied to any software using it. OTA model update done right.
"What if someone disagrees with a change?" they say. Well, in moste cases, people will disagree with the cosmetic aspect of a change. They won't like the way something is named, or they will think that some property is superfluous. I can understand that, but that doesn't mean that we should stop there. Can't we just, you know, let people customize their own data UI to match their preference? You don't want to see the 1000000 different properties people thought could be useful to represent an object? Feel free to hide them and use a template that only show you what you care about, such as the Model, Price and Brand. You don't like the term "Brand", and would prefere to call it "Manufacturer"? Feel free to set that synonym as the prefered way to represent this property locally. No need to reinvent the wheel there when we all agree with the semantics of the properties, but simply disagree on cosmetic details.
Not unlike a lawyer, the job of a programmer is to communicate effectively and accurately. Vocabulary is a powerful tool that let people communicate potentially complex ideas without having to explicitly define them. If they don't already know what a term mean, they can easily learn it using a dictionary. I believe it makes sense that developers should become vocabulary masters, and learn their way through common data models, as well as common relationships (roles) and actions (functions).
A great programmer shouldn't substract a person's birth date from the current date. It should know that this manipulation is called "Age", and simply call the "Age" property (which can be dynamic and calculate its value based on other values, on the spot).
Mastering a framework is a great way to become productive. Why can't the framework be universal, general-purpose, and closer to natural languages in term of scope? I mean, we already have dictionnaries that more or less define pretty much anything you would want to represent and/or compute. The code has to be written only once. The second time the code is written, it's wasteful. Unless writting the code is used as a way to search for an unknown term (reverse dictionary).
Our culture is plagued by the fear of reuse, by the naivety that everything you think of is novel. Once you realize that most of everything you can think of has already been thougth of before, you start to assume that a solution to your problems already exist, and you start to reuse what others have done. This is the only way to go forward, this is the only way to break through the next abstraction layer. We reached a point where the compiler is no longer the only tool that can save us time (by letting us write higher-level code). We reached a point where reusing what others are working on, in semi-real-time, is the most productive approach. As the web is slowly progressing toward 3.0, programming is just starting to gain the social aspect of the web 2.0. I'm not sure we will ever catch up.
Agents (people and/or machines) collect data to get a better idea of the world. The more you know about the world, the better you can navigate it. It let you make good decisions and accurate predictions. Collecting data is not good nor bad, it's just a natural process used to reach truth.
You used to have to collect all the data you needed yourself, leading to data duplication over distinct individuals. However, as communication improved, we started to delegate knowledge to third-parties. You no longer need to recall phone numbers by heart, as you can store this data in a cloud service you trust. However, we quickly realized that being too trusting can be a mistake, and that it is often necessary to spread data over an array of different knowledge base in order to make sure the data is not lost. This also helps with query speed and uptime, which is a practical bonus.
The way data will be exchanged in the future is quite obvious. Agents will gather data, and broadcast it over the network, to make sure that it's as available as possible. Nobody will care about where the data physically comes from or whether it exists in multiple places. Distribution and caching will all be done systematically for all data, and all you'll have to care about is the data itself. Once we have a good semantic framework and naming conventions, you'll be able to directly think about the data and completely ignore everything else. There won't be such a thing as "Facebook" and "Amazon" and "iTunes" and "Youtube". There will be People, Products, Music and Videos, and whether they come from service A or service B will be irrelevant.
The "API vendors" have 3 distinct jobs. First, they can act as relay/nodes that store/cache/distribute data. Second, they can act as functions/services that manipulate/transform data. Third, they can act as gateways with the physical world, acting as agents that read and write to the physical world (I/O). In any case, they offer an actual service, not data.
People will no longer pay for data. Data is cheap, data is easy to clone, data is easy to distribute. Therefore, data will be free and distributed without any restriction. However, people will still pay for the infrastructure, for the machines that serve them data on demand, for the machine that customize their data, for the machines that watch them, listen to them, talk to them. But data? People won't even imagine that data can or should be restricted, and won't care at all about the source of the data, they just want it fast.
The whole privacy issue is a non-issue that will resolve itself over time. It's not a technical issue, but a social issue. We don't have to fix privacy, we have to fix people. If there's anything accurate about this "API war", it's that privacy won't be a major concern. The real problem with the future described by the article is the inferior way APIs will communicate. They still require manual transaction, they still require the use of dirty adaptors to let APIs talk to one-another. This human intervention is not necessary, and semantic standards and ontologies are the key to this issue.
What could really take off is an API server platform that's decentralized and does authentication, api console, throttling, billing, etc.