How API Integration Evolved the Internet

API Integration and Evolving Internet

Once there used to be only static and non-interactive web-pages. Over time our way of using the internet started to change, along with the mindset of people. Users and businesses soon realized the hidden potential web-pages. With the introduction of search engines, websites started to focus more on market penetration. As a result, websites started becoming more interactive and intuitive. This coupled with a higher focus on customer experience throttled API development. Web APIs played a key role to make this change possible. In this article, we look at the brief history of how API integration has shaped the internet around us.


APIs are a rare example of the familiar, longstanding technology whose relevance continues to increase. From its humble beginnings as a static HTML based page. Today’s complex (almost computer software level feature-rich) and considerably interactive pages, APIs have managed to become the foundation of today’s internet ecosystem.


Today most SaaS Offerings, cloud platforms, mobile apps, and other IoT set-ups rely heavily if not entirely on APIs to operate. Let’s now look at some recent events that truly made API integration integral to the WEB.


REST VS. SOAP: The Great Debate

22 years ago, XML was developed at W3C with a dream of a truly semantic web. The web at that time only had relatively static web-pages that only humans could understand. The goal then was to change this by adding a new layer through which computers could talk to one another. But, a lot of developers at the time felt that XML didn’t give them enough freedom.


A few employees at Microsoft got together and started working on the Simple Object Access Protocol (SOAP). W3C adopted SOAP as a standard soon after its release. SOAP finally standardized and closed the loop between client and server. Standardizing web services enabled developers to build independent modules on top of projects they were working on. SOAP was considered to be rigid in its implementation due to the standardization of rules. In the end, SOAP helped developers create APIs, the middle link that lets users retrieve and update data from servers.


Roy Fielding meanwhile had some other ideas. He developed his own set of principles for web services called Representational State Transfer, or REST. REST did not advocate rigidness in its implementation. In fact, REST wasn’t even a complete set of technologies. REST was more a collection of design principles benefiting the already implemented HTTP methods.


As early as the 2000’s SOAP had gained a lot of popularity and Emerging companies like Salesforce, Yahoo and eBay started to create the first Open APIs using SOAP.


On the flipside, Fielding had gathered a lot of support from the community and big companies had finally started to notice REST. Companies like Amazon and Google along with Yahoo switched to REST and a lot of other companies followed. Raising the ever so popular question, “Rest Vs. Soap” Which is better? Eventually, developers started to emphasize the practicality of both and how in different situations one can be more beneficial than the other and vice versa. You can read more about this in one of our previous articles, where we explained the differences between REST and SOAP.  


To the Clouds: Cloud-Based API Integration

More and more businesses and websites started to adopt and integrate APIs. Soon it became clear that the previous no-frills approach had limits. These limits needed addressing, especially for public APIs. Around 2010 – 2011 there was a great push to further focus on Security, Analytics and Overall General control. This resulted in the release of first cloud-based API management products.


These quickly followed up by the early versions of tools and software targeted for REST contracts and documentation. Tools such as Swagger, I/O Docs and later RAML.


By 2014 the API industry had finally come to a consensus like what we see today. A robust set of services delivered and managed via standards-based API gateways. Solutions that started on these standards resulted in a safer and more controllable UI. With a strong emphasis on simplicity while delivering a clean and exceedingly user-friendly, UI.


Maturity Phase of APIs

With a much more fine-tuned UI experience API offerings matured and gained further popularity. Successful API providers now concentrated on further enhancing the feature set. With both the consumer and developer base growing, the competition was now shifting towards a streamlined development experience and community management.


Community events, press coverage, and efficient live documentation started to become important tools in implementing API Strategy.


These rising standards of what constitutes a state-of-the-art API had a huge impact on the whole industry. Eventually, some established providers had to rethink their offerings, resulting in second-generation APIs.


Second Generation APIs now had naming conventions, data formats, version management and a lot of other enhancements.


New Age of Possibilities

Recently the focus has shifted to API Usability improvements, this might leave the uninitiated to believe that API Technology has finally reached a plateau. This would mean that further growth, adoption and consequently development will be slowed.


Contrary to the above we believe that this is just the beginning. APIs finally are now at such a level where there is no limit for creative minds. With more efficient ways being devised to access services and describe contracts through GraphQL and new approaches for Data Sharing (DaaS) emerging. In addition to these, recent industry standards like PSD2 introduced to address interoperability challenges from the provider’s point of view.


Another form of innovation is Digital Assistants, Chatbots and low-code platforms which are the leading client driver API Innovations. These few instances are just the tip of the iceberg. Perhaps they will one day completely change how we write APIs, interact with computers and the way computers interact with each other.


The Commercial Side of API Integration

There are a ton of APIs available on the web today. Companies and organizations have started to rely heavily on their API infrastructure to serve their core client base. While there are a lot of free APIs available some businesses even charge a hefty amount to allow access.


Companies such as Netflix served more than 5 billion API requests in 2014. APIs such as Word API or Utelly API have implemented paid plans for developers to make another revenue stream for their businesses.


Global Impact

Governments have huge amounts of data collected over the years. Some governments have now opened up access to this date for public use. The interface through which this data is distributed and/or accessed is a Web API. Web APIs allow for data accessibility by a developer easily and securely. This can range from budget, crime, public works, legal and any other agency data the government chooses to share.



We hope that by reading this far you would have got a generic idea of Web APIs and how they were created out of necessity rather than desire. Since their invention APIs have been going through a constant and incremental evolution. It was only through this evolution that the internet developed into what we experience right now.


From static pages to complex and demanding web applications interacting with multiple computers and APIs. There are limitless possibilities for a developer through API Integration.


Finally, we can say that APIs have become the bridge between consumers and providers ranging from small companies, giant corporations and all the way to governments.

Share this :

Share on facebook
Share on twitter
Share on linkedin
Share on pinterest



Would you like to start a project with us?

Get in contact with Help Square for a free, no catch quotation. Or get in touch for some free advice! We are here to help.