Kin Lane recently wrote a couple of blogs about why copyrighting an API is not common. I couldn’t agree more that copyrighting APIs is uncommon. First of all, the API definition is just an interface (It is the implementation detail that is important, and needs to be guarded), so it doesn’t make any sense to copyright an interface. (It is almost like copyrighting a pretty face ). Secondly, the whole idea of exposing an API is you are looking for others to finish the work you started by just providing the plumbing work. Why would anyone want to get involved with a copyrighted API and finish your work for you?
Kin Lane says, “API copyright would prevent the reuse and remix of common or successful API patterns within a space. We are at a point where aggregating common, popular APIs into single, standardized interfaces is emerging as the next evolution in web and mobile app development.”
We have gone from the services aggregation concepts to mashups, and now I am seeing the newer trend of API aggregation.
Keep in mind APIs are generally offered by vendors who want to expose a specific functionality or platform. If you need cross platform, cross provider, cross functionality options, you need to have API aggregations. Remember during the services days how much of a hard time we used to have in integrating and aggregating services from different vendors? I know some companies are making a good living by just building aggregated APIs.
One of the common usage patterns I see time and again is customers use the strongest points from vendors of their choice. This was not possible when you were building services. You ended up buying one vendor stack, and you were limited what was offered by them, unless you custom built the weak parts by yourself.
Now imagine the power of what you are getting now. You are cherry picking the best of breed platforms, best of possible functionalities from multiple vendors of your choice and liking.
I highly encourage you to check out Intel® Mashery’s API Management platform.