In January of 1999, Darcy DiNucci, a consultant on electronic information design, wrote:
"The Web we know now, which loads into a browser window in essentially static screenfuls, is only an embryo of the Web to come. The first glimmerings of Web 2.0 are beginning to appear, and we are just starting to see how that embryo might develop. The Web will be understood not as screenfuls of text and graphics but as a transport mechanism, the ether through which interactivity happens. It will [...] appear on your computer screen, [...] on your TV set [...] your car dashboard [...] your cell phone [...] hand-held game machines [...] maybe even your microwave oven."
In the early days of the Internet, the World Wide Web was static. A majority of the users were consumers and very few were creators. The Web contained electronic representations of various resources, such as a magazine or an encyclopedia. As public demand for rich user experience, user participation, dynamic content, metadata, web standards, and scalability, increased only websites that adapted survived. Corporations also realized the value of information and that they could monetize it, if they were willing to expose their internal datastores through public APIs.
These public APIs allow web communities to create content in one location and share it in multiple locations. For example:
- Photos can be shared from sites like Flickr or Photobucket to social network sites like Facebook or MySpace.
- Content can be embedded; for example embedding a presentation from SlideShare on a LinkedIn profile.
- Content can be dynamically posted; for example sharing live comments made on Twitter with a Facebook account.
- Video content can be embedded on sites served by another host.
User information can be shared from web communities to outside applications, delivering new functionality to the web community. As system complexity increased, developers needed a more structured way of communicating between the different components. This eventually grew into a formal multi-tiered model with private APIs making up the middleware; this model is covered in more detail in the What makes API Testing special? article. The public APIs are just a natural evolution of the complexity and need for extra-corporate interactions.
The Semantic Web
On today's World Wide Web everything is interconnected, and every user is both a consumer and a creator. Almost every website has instant Twitter feeds, targeted Google AdWords, and a multitude of other widgets from third-party providers. Any website can be an API provider, an API consumer, and an end user, all in one.
The number of private and public APIs has been growing exponentially in last several years and is projected to only continue to rise. At the time of this writing, ProgrammableWeb contains a searchable directory of over 10,500 public APIs. Craig Burton, an industry analyst, predicts the number of public APIs to reach 30,000 by 2016, with others predicting around 1 million APIs by 2017. Furthermore, he estimates that private APIs grow at a rate of 5x to that of public APIs. Keep in mind that private APIs – sometimes called “dark” APIs, because they are not as visible – make up both a much larger and more mature segment of the market. Large enterprises were the first to invest in developing APIs, and as more systems were added so were the number of APIs. For some very large enterprises, like conglomerate banks, the APIs are so numerous and complex, they have to be orchestrated through an ESB – Enterprise Service Bus. The exact number of APIs, even reasonable estimates, are therefore very hard to quantify.
Rise of The Enterprise
Corporations that became successful during the Industrial Age used business strategy of secretly protecting their business assets and making use of vendor lock-in to gain advantage over their competition. This tactic, when applied in the Information Age, is often unsuccessful as it alienates, and some cases punishes, your customers. This can be seen from the traditional newspaper, movie, and music industries. The so called “API Economy” is changing this philosophy. Instead of hiding their assets, successful companies are now exposing them through APIs. Even the slow-to-change mega-corporations and governments are starting to see the benefits of exposing their services through APIs. Some of the benefits include: decreased development costs and time by having software produced by user community, wider coverage of different platforms and devices, expanding into new markets that you perhaps would not be able to reach on your own, influencing industry standards, building new partnerships, and benefiting from open innovations of crowdsourcing.
The proliferation of mobile devices increases the corporate need for APIs even more. Business leaders face a problem: the APIs they provide have no business value in and of themselves, but it is critical to make available the paid services and data they provide.
The motivations behind developing an API can vary. Guillaume Balas, CMO at 3scale, discussed some possible business roles of the API:
- The API could be the product itself, such is the case with Skype or Twilio. This generates direct revenue for the company.
- The API projects the product, like for example SalesForce.com, FedEx, or eBay. In this case the API reaches places where the product otherwise would not be able to go.
- The API promotes the product, which can be seen from the likes of Amazon, Expedia, or Netflix. In this case, the API generates business leads and promotes the brand.
- Lastly the API powers and feeds the product, such as Twitter, or YouTube. Here the API helps to acquire content and solidifies partnerships.
Of course opening up your internal processes can present some technical challenges. Sharing your data could lead to increased security risks and privacy concerns. This leads to a need for new or at least improved security-related technologies and solutions. Once your API establishes a user base, you need to maintain reliability and trust in the exposed APIs.
Most of your end-users will not even be aware of the API, until it stops working. The API will evolve, but how do you maintain API compliance and backward compatibility? Developing effective and efficient API is an architectural challenge (covered in the What makes API Testing special? article). It can be challenging to maintain applications and services that rely on a combination of multiple APIs that keep evolving over time.
Of course not all challenges are technical in nature. Attracting consumers, having a successful API marketing strategy, and managing the API ecosystems are all important considerations as well. The API Testing Dojo intends to be a resource you can leverage to help you survive in the API Economy.
https://www.soapui.org/testing-dojo/world-of-api-testing/why-test-.html