How to Learn APIs? Complete Guide for Beginners
“APIs are everywhere” – This is a statement that was considered to be distant a few years ago and has now become a reality. The demand for software applications has changed from before. Earlier, the demand was to create software that performs a certain functionality. Now the demands have altered to make the same software not only perform the function correctly but also render results in the least amount of time possible and offer additional functionalities with the major functionality of the software.
Offering such complex code with the least time complexity and minimizing the bulkiness as much as possible has only been able to come to life due to the use of microservices in the system architecture of all applications we see and use every day. These microservices are APIs.
APIs or application programming interfaces are pieces of code that offer software the power of communication, sending and retrieving information, and work with a well-defined set of protocols to offer the developers the tools they require to ease their software development process and offer the customers the speed, accuracy and the quality of service that they are paying for.
REST, or representational state transfer, is a standardized stateless way of establishing communication between a client and a server that offers huge scalability and performance options. A REST API can be viewed as a middleman which facilitates the exchange of requests and responses between the client and the server. We can understand this with the help of an example. Let’s say that you are running a bookstore and you have made a web application that allows people to view new arrivals, buy books, and allows your store operators to edit information as well.
The author assumes that the reader is aware of CRUD operations – Create, Read, Update and Delete. These CRUD operations are mapped as HTTP requests in the form of POST, GET, PUT and DELETE requests.
A request that is made from the client to the server via a REST API consists of four major components – a header that contains information about the client requesting the resource and authentication information (if any), an operation that is essentially a POST / GET / PUT / DELETE request, an endpoint which is a URL from where the resource can be accessed or modified and the body of the request which consists any information that needs to be sent along with the request. The response from the server can be in XML or JSON format.
Considering the example of a bookstore that we took above:
- When a customer requests the list of books, an API endpoint which is
https://bookstore.com/api/books, is hit with a GET request. When the request reaches the server, the server responds back with a JSON object containing details about the books, which are displayed to the user.
- When a customer buys a book, that book is removed from the bookstore. The API endpoint
https://bookstore.com/api/booksis hit with a DELETE request along with the id or the name of the book, which deletes the entry of the book. The server responds back with a status 200 if the book has successfully been deleted.
- When changes have to be made to the details of the book, the store operators make a PUT request to the API endpoint
https://bookstore.com/api/booksalong with the id or the name of the book as parameters and the content to be updated. The server responds with a status 201 if the book has been updated successfully.
- When a new book that has come to the store has to be added to the bookstore, the store operators must make a POST request to the API endpoint
https://bookstore.com/api/booksalong with the data of the new book. The server responds back with a status 200 if the new resource (new book) has successfully been created.
SOAP, or simple object access protocol is a means of communication just like REST APIs but with a fundamental difference – it follows strict rules. It can only facilitate communication in XML format. If we draw a contrast between REST and SOAP APIs in order to understand better, REST APIs are independent, and they can attach themselves to HTTP to travel between the client and the server; however, the SOAP APIs require to be wrapped in a gift box before they can travel with HTTP between the client and the server. SOAP-based APIs are involved in places where there is a need for sensitive information exchange like banking information, payment gateways, etc. since SOAP contains asset compliance which offers a high level of security to the communication. SOAP uses an “envelope” to wrap the request body. The data is sent and received in XML format, which makes coding a little more difficult than REST APIs and also decreases performance since the XML code has to be converted to a human-readable format.
When a request is sent via a REST API, the entire data is sent back, and there is no way to obtain specific fields, which results in bulky data being exchanged. GraphQL is a query language that eliminates this and makes the client side more robust with specific methods for obtaining only the necessary data and decreasing the payload that is received from the server when a request for a resource is made.
GraphQL is a query language that can be coupled with any existing API architecture, be it REST or SOAP, or any other database from where information has to be fetched in a manner that makes the applications run faster and only get the data that is actually supposed to be used on the client side. First and foremost, a schema is created in GraphQL, which is then mapped to the backend to ensure that the backend and GraphQL both understand what data we are requesting and when. To access the data from the server side, you need to write queries for the same and let the magic happen.
Web socket APIs are used to facilitate real-time communication. When we use a REST API, a client sends a request, and then the server sends back a response, and the cycle continues each time a message has to be relayed between the client and the server. However, web sockets facilitate duplex communication. This means that neither the client has to wait for the server to send a message nor the server has to wait for the client to send a request. Both the client and the server can communicate simultaneously. In addition to this, it is also faster and less bulky than REST APIs when it comes to real-time communication, as there is no need to establish a new TCP connection every time a message has to be sent between the client and the server. Unless a connection is closed explicitly, the same TCP connection stays alive and facilitates communication via the stateful web socket API.
Let us now recap what we have discussed. We understood the what, why, and how of APIs and looked at four different kinds of APIs – REST APIs, SOAP APIs, GraphQL Based APIs, and Web Socket APIs. Each kind has its own pros and cons; however, broadly, we can understand that – REST is the easiest to implement, SOAP provides security, GraphQL provides more control over what data has to be achieved without defining explicit client-specific endpoints, and web sockets make real-time communication possible without any latency. Readers are encouraged to look up the implementation of these kinds of APIs. One can use Postman to build and test all kinds of APIs in a seamless manner.
Read more about learning paths at codedamn here.
Sharing is caring
Did you like what Pooja Gera wrote? Thank them for their work by sharing it on social media.
No comments so far
Leave a question/feedback and someone will get back to you