Inception of Web APIs and their evolution

Looking back to the days when the ASP.NET ASMX-based XML web service was widely used for building service-oriented applications, it was the easiest way to create a SOAP (Simple Object Access Protocol)-based service that could be used by both .NET applications and non-.NET applications. It was available only over HTTP.

In the late 2007, Microsoft released Windows Communication Foundation (WCF). WCF was and is, even now, a powerful technology for building SOA-based applications. It was a giant leap in the world of the Microsoft .NET world.

WCF was flexible enough to be configured as an HTTP service, remoting service, TCP service, and so on. Using the contracts of WCF, we would keep the entire business logic code base the same, and expose the service as HTTP-based or non-HTTP-based via SOAP/non SOAP.

Until 2010, the ASMX-based XML web service, or WCF service, was widely used in client-server-based applications; in fact, everything was running smoothly.

But the developers of the .NET and non-.NET community started to feel the need for a completely new SOA technology for client-server applications. Some of the reasons behind this were as follows:

• With applications in production, the amount of data used while communicating started to explode, and transferring them over the network was bandwidth consuming.
• SOAP, being lightweight to some extent, started to show signs of payload increase. A few KB SOAP packets would become a few MB of data transfer.
• Consuming the SOAP service in applications led to huge application sizes because of WSDL and proxy generation. This was even worse when it was used in web applications.
• Any changes to the SOAP services led to updating the service proxy to reflect changes. This wasn't an easy task for any developer.
• JavaScript-based web frameworks were released, and gained ground for a much simpler way of web development. Consuming SOAP-based services was not that optimal.
• Hand-held devices, like tablets and smartphones, became popular. They had more focused applications, and needed a very lightweight service-oriented approach.
• Browser-based Single Page Applications (SPA) gained ground very rapidly. Using SOAP-based services was quite heavy for these SPA.
• Microsoft released REST-based WCF components, which can be configured to respond in JSON or XML, but still it was built on top of heavy technology of WCF.
• Applications where no longer just large enterprise services, and there was a need for a more focused, lightweight, and easy-to-use service, which could be up and running in a few days.

Any developer who has seen the evolving nature of SOA-based technologies such as ASMX, WCF, or any SOAP-based technology, felt the need to have much lighter, HTTP-based services.

HTTP-only, JSON-compatible POCO (Plain Old CLR Object)-based lightweight services was the need of the hour, and the concept of Web APIs started gaining momentum.