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.

APIs in the Early Internet Age

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, .NET and XML

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.

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

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.

Application Service Providers

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.

Conclusion

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:

• Download "The Evolution of APIs: From RPC to SOAP and XML" eBook today
• Read Part 1 of this blog post