Hello geeks, there are tons of blogs all over the internet about APIs; this one is no different. I'm still a curious explorer in the field of web and full-stack development, and these blogs are my attempt to document my journey from beginner to being a proficient developer. Before we dive in, I want to be upfront with you all—while I strive to provide accurate information, I'm still learning myself. So, consider this blog as a fellow explorer's journal rather than a definitive guide. Now that being said, let's begin our journey into the world of APIs!
An Application Programming Interface (API) serves as a crucial intermediary between different software systems, much like a skilled waiter in a restaurant. Let's delve into this analogy further by considering the dynamics between the customers (clients), chef (server), and waiter (API).
What does an API do?
Imagine you're dining at a restaurant. You, the customer, have specific preferences and requirements for your meal. However, you can't directly communicate with the chef who prepares your food. Instead, you rely on the waiter to convey your order accurately to the chef and deliver the finished dish back to you.
Similarly, in the realm of software, clients (applications or systems) have specific tasks they need to accomplish or data they require. However, they can't directly interact with the server (the system or service that provides the desired functionality or data). This is where the API steps in as the intermediary, just like the waiter in our restaurant analogy.
The API receives requests (orders) from the client, processes them, communicates with the server to fulfil the request (conveying the order to the chef), and then returns the desired information or functionality back to the client (delivering the dish to the customer).
Different types of API’S
There are various architectures employed in APIs, with some of the most popular ones being
- RESTful APIs
- GraphQL APIs
- WebSockets
- RPC APIs
Let's delve into each of these architectures individually to gain a deeper understanding of their principles and functionalities.
Representational State Transfer (REST)
Representational State Transfer (REST) is an architectural style devised to establish standardised practices within web systems. RESTful systems are characterised by their statelessness and the clear segregation between clients and servers. To qualify as RESTful, an API must adhere to specific constraints, which we will now examine in detail.
Statelessness
Statelessness means that every time a client sends a request to the server, the server treats it as an isolated event, without any memory of previous interactions. It doesn't retain any information about the client between requests, making each interaction independent. As a result, clients are responsible for managing their own session information to maintain continuity. This approach not only aids in scaling servers to handle increased demand but also reduces complexity by eliminating the need for server-side storage and management of client data.
Uniform Interaction
Irrespective of the device the way it interacts with the server remains the same we need to follow certain principles to have a uniform interface:
Resource Based and unique identification: each request is interacting with only one resource and there should be a way to uniquely identify a resource usually expressed as a URI (Uniform Resource Identifier), this will standardise the way client interacts with the resources on the web
Self Descriptive Messages: the messages exchanged between the client and the server must contain the information required to process the data and understand the data, this is usually done by using headers and formatting the structure of data
Hypermedia as the Engine of Application State (HATEOAS): It needs to include links for each response so that clients can discover other resources easily.
Cacheable
Every response should include whether is cacheable or not, if yes then for what duration should the cached data is use for subsequent requests instead of sending a request to the server this will increase the performance and availability
RESTful Interaction
RESTful systems primarily use http verbs for interaction the client uses a verb like GET to make a request to the server and then the server responds with some data and a status code, below are few most popular HTTP Verbs,
- GET: Retrieves data from the server. It should not have any side effects on the server.
- POST: Submits data to be processed to a specific resource. It can create new resources or perform other actions like updating or deleting existing resources.
- PUT: Updates data of a specific resource. It replaces the existing resource with the new data sent in the request.
- DELETE: Removes data of a specific resource.
A glimpse of how RESTful systems interact
Client Request:
GET /books/123 HTTP/1.1
Host: example.com
Server Response:
HTTP/1.1 200 OK
Content-Type: application/json
{
"id": 123,
"title": "The Great Gatsby",
"author": "F. Scott Fitzgerald",
"publishedYear": 1925,
"genre": "Fiction",
"isbn": "978-3-16-148410-0"
}
In this example, resource operations are clearly distinguished by unique identifiers, exemplified by the "id" attribute. The system adheres to the stateless nature of REST architecture, wherein interactions solely influence resource states, ensuring independence from prior requests. Additionally, the response message provides comprehensive metadata, promoting clear comprehension, with the presence of the 200 status code affirming the successful execution of the client's request.
Conclusion
In summary, this blog has served as an introductory guide to API architectures, focusing on the principles and functionality of RESTful APIs. We've explored how RESTful systems operate with clarity and statelessness, enabling seamless client-server interactions. Our exploration culminated in a practical example, illustrating the clear and concise nature of RESTful interactions.
As we conclude our discussion on RESTful APIs, stay tuned for our next topic: a beginner's exploration into GraphQL APIs. In our next installment, we'll delve into the world of GraphQL and uncover its unique approach to data querying and manipulation.
Thank you for joining us on this journey through API architectures. Until next time, happy coding!
Top comments (0)