In our last blog post, we discussed the evolution of APIs from early computing to the PC era. In this post, we'll discuss the evolution of APIs in the early internet age. Along the way, we'll touch upon associated core technologies such as eXtensible Markup Language (XML) and discuss the introduction of web services and its common components: SOAP and WSDL.
Coming into the late 90s and the early years of this century, enterprises realized the potential of the internet to do more than just deliver their public-facing corporate websites; they could use the internet to provide application services.
Java had been in the market for some time as an established product. Interactive Java applets were used heavily as embedded objects in websites. The natural tendency was to host the application in middleware—in this case, a Java Application Server. These applications were known as Enterprise Java Beans (EJB) components.
At the start of the century, Microsoft released .NET, a new framework that included the Common Language Runtime (CLR) and an extensive class library (such as ADO.NET for database connectivity or ASP.NET for web applications). Programming languages other than the ones developed by Microsoft could create .NET applications as long as they were using the framework. Like Enterprise Java, .NET also allowed creating distributed applications.
Another development around that time was eXtensible Markup Language (XML). XML is a data interchange mechanism that allows anyone to create a set of rules to encode data. Using XML, exchanging data between applications (and even between companies) suddenly became vastly simplified. All they needed to do was agree upon an XML schema for the data they would exchange for two communicating applications.
Distributed computing was maturing, with different technologies and languages available. The development of application servers and platform-independent components shifted the focus of innovation toward finding a common protocol that would allow humans and applications to access remote applications, no matter where they ran. That protocol was HTTP, and the messaging format was XML, thus beginning the journey of web services.
A web service is a piece of self-contained software accessible over HTTP. The client and the web service could be written in different languages and run on different computers separated by oceans and connected via the internet.
The reason clients and web services can be platform and language-independent is because they exchange information in XML. When a client wants to invoke a web service, it sends an XML message. The web service performs the requested operation and sends the result back in XML as well. The communication between the client and the web service happens over HTTP.
Apart from HTTP and XML, two other components are common to web services: SOAP and WSDL.
The Simple Object Access Protocol (SOAP) is a lightweight messaging framework for clients and services to exchange standardized XML data over a network. It uses XML as its message format. SOAP is relatively rigid in how it stipulates the request and response syntax. For message transfer, SOAP uses the application-layer protocols HTTP or Simple Mail Transfer Protocol (SMTP). SOAP is still used by some web APIs today.
Web Services Description Language (WSDL) is an XML-based language to describe the functions of a web service. Remember that XML allows you to create custom, tag-based message formats— WSDL is just that. This is a document that a web service uses to describe its functionality and clients to find a web service.
Data serialization is a technique that breaks up the data objects of an application into a stream of bytes for transferring across a network. The serialization process ensures that the state of the data object is saved before it's transmitted. Serialization is necessary for complex computer data structures (for example, nested arrays). On the receiving end, a deserializer constructs the data object from the byte stream.
Using a text-based, human-readable serialization format like XML (and later JSON) meant the message format could be changed any time. For example, if the web service needs to expose a new data field, this means changing the XML message schema. In other words, message formats were now loosely coupled to the functionality of the application.
The rise of web services also saw a new type of business. These companies were known as Application Service Providers (ASP), and their introduction brought about what we know today as software-as-a-service (SaaS) providers.
The ASP emerged to remove the burden of developing, hosting, managing and upgrading applications from enterprises. Instead, an ASP would develop a business application, host it in its own data center and provide application access to clients for a fee.
The collective momentum of the software industry has continued to shift the landscape for modern web APIs. Knowing the history of modern web APIs allows us to better understand them. In this two-part blog series, we discussed the evolution of APIs from early computing through pre-internet modern computing and right up through the early days of the internet. To learn more:
This is part of a 3-part series on APIs, sustainability, and climate change. Check out part 1 on managing a greener API lifecycle, and part 2 on ways to embed and innovate on top of third-party APIs to make greener products. In this final part
The API management space is changing - fast. In the past couple of years alone, we've seen huge changes in the deployment patterns that our customers are adopting. In the past, when the use cases were fairly simple, organizations would deploy an
To work and live in today's digital world, we are unquestionably dependent on interconnected applications . These applications might be massive and highly complex, but they're also constructed from reusable building blocks, which we call an Applica
The challenges of an acquisition frequently appear in a number of critical areas, especially when dealing with a platform as important as Kafka: API Instability and Change : Merged entities frequently rationalize or re-architect their services, whic
Everyone's telling you to innovate faster with AI. Move quicker. Ship more features. Deploy more agents. But before we sprint headlong into the AI revolution, we need to have a proper dollars-and-cents conversation that most companies are avoiding.
Introduction: It’s a great report for us here at Kong, and it further validates the changes happening in the larger market The 2025 Gartner Magic Quadrant for API Management report was a great one for us here at Kong. We continue to move “up and to
The challenge: A disconnected world Consider the typical enterprise architecture in a relatively mature organization, an API management layer defines and deploys services to an API gateway, an Identity Provider (IDP) manages human user identities, a