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:
Ever feel like you're fighting an uphill battle with your API strategy? You're building APIs faster than ever, but somehow everything feels harder. Wasn’t API-first supposed to make all this easier? Well, you're not alone. And now industry analys
Survey Says: Google LLMs See Usage Surge, Most OK with DeepSeek in the Workplace Enterprise adoption of large language models (LLMs) is surging. According to Gartner , more than 80% of enterprises will have deployed generative AI (GenAI) applicatio
Kafka delivers massive value for real-time businesses — but that value comes at a cost. As usage grows, so does complexity: more clusters, more topics, more partitions, more ACLs, more custom tooling. But it doesn’t have to be that way. If your tea
A Practical Look at When (and When Not) to Use Ambient Mesh The word on the street is that ambient mesh is the obvious evolution of service mesh technology — leaner, simpler, and less resource-intensive. But while ambient mesh is an exciting develop
I'm commonly asked by customers for advice on how they can build a good platform cross-charging model for their organization. And my gut reaction is nearly always "don't." We'll come back to why I think that later, but first let's look at what cross
Unify the API and Eventing Developer Experience with the Kong Event Gateway and API Platform Introduction: The EDA and API worlds are converging . . . finally For the past several years, there have been murmurs of an incoming convergence between API
The world of artificial intelligence is undergoing a seismic shift, with the emergence of agentic AI redefining the landscape of API development and management. As businesses and developers navigate the complexities of digital transformation, unde