Evoluton of API

APIs are omnipresent in today’s digital ecosystem, serving as the backbone of web and mobile applications. For developers and tech professionals, comprehending the nuances of API implementation and consumption is non-negotiable. Let’s embark on a journey through the evolution of APIs, understanding how they’ve morphed into the present standard.

What does an API stands for? API is an acronym for the Application Programming Interface. In a nutshell:

At their core, APIs are contracts. Formulated on supported protocols, they demand adherence from involved parties to ensure consistent and dependable communication.

Its been 25 years already

In the beginning, there was SOAP (Simple Object Access Protocol), a cornerstone in the realm of web services. This protocol, pivotal for exchanging structured information, harnessed XML for its message format. Typically, it operated atop other application layer protocols such as HTTP or SMTP, orchestrating message negotiation and transmission with precision. SOAP wasn’t just a protocol; it was an ensemble of three critical components, each playing a vital role in the orchestration of web services.

• Envelope: Defines the start and end of the message.
• Header: Contains any optional attributes of the message used in processing the message, either at an intermediary point or at the ultimate end-point.
• Body: Contains the call and response message.
• Fault: An optional Fault element that provides information about errors that occurred while processing the message.

Developed by Microsoft and first released in June 1998, it quickly became a standard for building APIs, recommended by W3C in 2000.

The dawn of the 2000s heralded the advent of REST (Representational State Transfer), a paradigm shift towards Stateless Communication. In this architecture, each client-server request is self-contained, packing all necessary data to comprehend and execute the operation.

REST operates on the Client-Server Architecture, a strategic separation that boosts scalability and portability. Its hallmark feature, the Uniform Interface, streamlines and decouples the system architecture. This not only simplifies interactions but also fosters independent evolution of different components. REST capitalizes on standard HTTP methods like GET, POST, PUT, PATCH, and DELETE, embracing the stateless nature of HTTP to its core.

Data exchange with the client predominantly takes the form of JSON or XML, although REST is versatile enough to accommodate other formats. The integration of HTTPS adds a layer of security, encrypting the data in transit.

Diving into the components of REST, we uncover:

• Resources: The key abstraction of information in REST; any information that can be named can be a resource.
• Resource Identifiers (URIs): Resources are manipulated using a fixed set of operations (HTTP methods).
• Representations: After accessing a resource using its URI, the client receives the resource’s representation, which can be in various formats such as JSON, XML, HTML, etc.

By the end of 2000s it already became dominant protocol for building APIs, moving SOAP sideways and eventually making it a legacy protocol. REST maintained its prominence by the present day and representing a golden the standard in API development.

As the late 2000s unfolded, the tech landscape witnessed the emergence of two groundbreaking protocols: GraphQL and OData, pioneered by Facebook and Microsoft, respectively. GraphQL, a project initiated in 2007, underwent nearly a decade of development before its public debut in 2015, followed by a formal specification in 2016. This timeline culminated in the establishment of the GraphQL Foundation under the Linux Foundation’s auspices in 2018.

Designed as an open-source data query and manipulation language for APIs, GraphQL revolutionized how clients interact with data. Its key strength lies in empowering clients to request precisely what they need, no more, no less. This approach elegantly circumvents the pitfalls of over-fetching or under-fetching data, ensuring efficient and tailored data retrieval. Diving into the components of GraphQL we identify:

• Schema: The schema defines the capabilities of the API by specifying types and the operations (queries and mutations) available.
• Resolver: Functions that handle the queries and mutations, retrieving and manipulating data.
• Queries and Mutations: Queries are used to fetch data, and mutations are used to modify data.
• Subscriptions: A feature that enables real-time data updates.

Parallel to GraphQL, OData (Open Data Protocol) was carving its niche in the API landscape. Its journey began in 2007 as part of ADO.NET and continued until 2014 when version 4.0 launched, marking its standardization by OASIS (Organisation for the Advancement of Structured Information Standards). OData stands as an open protocol, tailor-made for constructing and consuming RESTful APIs. It distinguishes itself by offering seamless integration with diverse data sources, enhanced querying capabilities, and robust data manipulation, all via standard HTTP.

OData excels in scenarios where the complexity transcends typical REST applications, thanks to its comprehensive standards for querying and updating data. The protocol is not just about data access; it’s about delivering sophisticated and efficient data interactions.

Key components of OData include:

• Service Document: Lists the available collections of resources.
• Metadata Document: Describes the types of data and relationships between them.
• Resource Paths: Identify the specific data to be accessed or manipulated.
• Query Options: Allow clients to modify the data request, like filtering, sorting, and pagination.

In 2008, the HTML5 specification introduced WebSockets. This communication protocol enabled full-duplex communication channels over a single TCP connection, complemented by an HTTP-based initial handshake. This means remarkably low overhead, a significant advantage in the world of web communications.

WebSockets shine in scenarios demanding real-time, bidirectional data flow between client and server, such as in chat applications or live updates. Once a WebSocket connection is established, it remains persistently open, facilitating a seamless two-way communication stream.

In environments where WebSockets are not supported, fallback mechanisms like long polling are employed to maintain functionality. The communication process using WebSockets involves distinct stages, each critical for maintaining a stable and efficient connection. These stages of communication using WebSockets include:

• Opening Handshake: The connection starts with an HTTP handshake that is then upgraded to a WebSocket connection.
• Data Framing: Messages are framed in a consistent and compact way to allow for efficient data transfer.
• Close Handshake: Either the client or server can initiate a closing handshake to terminate the connection.

We can’t conclude our API journey without discussing gRPC, an acronym for Google Remote Procedure Call. Originating from Google’s innovative corridors as an enhancement to its internal RPC systems, gRPC was open-sourced and introduced to the public in 2015. A year later, it found its place under the auspices of the Cloud Native Computing Foundation, an entity dedicated to nurturing cloud-native computing ecosystems.

At its core, gRPC is designed for high-efficiency communication, making it a go-to choice in the realm of microservices architectures. It employs Protobuf (Protocol Buffers) as its interface description language, which is a key factor in its efficiency and speed superiority over traditional REST APIs, particularly in contexts characterized by low bandwidth and high latency. Moreover, gRPC is adept at supporting streaming requests and responses, a feature that further amplifies its utility.

The components of gRPC, pivotal in crafting robust and efficient communication frameworks, include:

• Protocol Buffers: A language-neutral, platform-neutral, extensible mechanism for serialising structured data.
• Service Definition: Service methods and their message request and response types are defined in .proto files.
• Server and Client Stubs: Auto-generated code based on .proto files, facilitating easier client-server implementation.

Subscribe

For more stories like this, from software engineering feel free to subscribe to https://softwareengineeringcrafted.substack.com/