# What is an API? Types of APIs Explained | System Design | 6

## Метаданные

- **Канал:** Telusko
- **YouTube:** https://www.youtube.com/watch?v=UmYVFGCwg2w
- **Дата:** 27.04.2026
- **Длительность:** 12:52
- **Просмотры:** 3,855
- **Источник:** https://ekstraktznaniy.ru/video/49263

## Описание

APIs are the backbone of modern applications, but what exactly are they, and why do we need them?

In this video, we break down APIs from a System Design perspective — starting from the understanding APIs, to understanding its types.

You’ll learn:
• Why APIs are needed in modern development
• How frontend, backend, and different services communicate

We also cover different types of APIs:
• REST (JSON-based, most commonly used)
• SOAP (XML-based, legacy but still used in enterprises)
• GraphQL (flexible data fetching)
• gRPC (high-performance communication)
• WebSockets (real-time communication)

Whether you're preparing for interviews or trying to understand real-world systems, this video will give you a solid foundation.

Check out our courses:

DevOps Bootcamp: https://go.telusko.com/complete-devops
Coupon: TELUSKO10   (10% Discount)

Industry-Ready Spring Boot, React & Gen AI -Live Course : https://go.telusko.com/industry-ready-springboot
Coupon: TELUSKO10   (10% Discount)

Master

## Транскрипт

### Segment 1 (00:00 - 05:00) []

Hello everyone, welcome back to the school. In today's video, we are going to discuss about APIs. Have you ever wondered if you see Zomemetto, if you see Uber, if you see Ola, if you see Rapido and all these applications also Swiggy, they all have an inbuilt map. But did they create their own map in their applications or do they use the existing Google maps in order to do that? Now that is possible only through APIs. So Google maps presents some APIs to other applications which they can use. Now in order to understand APIs in detail, let's dig into this video and go to our screen. If we think about API, the API basically stand for application programming interface. Now what does this mean? Suppose this is our application. Any application will work. Let's say this is a movie application. in which we have all the movies plus ratings all the reviews of the movie like IMDb or something okay like Rotten Tomatoes or something so we are already capturing all the details which includes a movie like latest movie latest hits of 2000 2010 2020 everything now we already have this amount of data which is stored in our database and our application is already working on that let's say now in any other corner of the world. Someone is trying to create one application based on the data which is already captured in this app. Now they have two option either they can create their own engine like this their own application where they will again curate all the ratings, curate all the reviews and curate all the data. But now where are they going to curate this form? For this every application leaves some end points which can be used by another application. Now if for our application or for this developer application if they want to use rating of some movie application they can directly call the APIs of this application and through which they will get the proper information which is required for them. Now like this developer or this application don't have to create their own application for the task which is already been done. So they can use the application data directly. But again can't we directly give access to our database? This can be dangerous right because then this application again have to handle a lot of scenarios based on the database queries. Plus they can also delete some important data in this database which will affect the other applications which are using the same content. Also there are some added functionalities. Let's say we are giving an option to write a review again. So in this we have already handled that case through some or the other API. So instead of creating a new endpoint in this application we can directly access the endpoint of the other application which is going to take our review also. So in this case this application saves a lot of time because they are using another application the APIs of another application through which they are going to do the same work. Now in this case if this application wants to add some data into their database also they can easily do this. So this is one use case of creating an API or using APIs of other application. Also there can be a case where you're creating an application and in the back end you are exposing the APIs which can be used by your front end. So front end can be a web application or even a mobile application can be both also. Let's say we are creating some back end and from for the application we are also creating front end maybe using react or something and back end using swift or something. In both of these cases these languages the react and swift both are capable of handling APIs. So they don't care about which language did the backend use in order to provide them the API. They will directly call the APIs and use the information which they are trying to use. So this is another scenario where there are no two applications. There is only single application which is divided into front end and back end part and using the data which back end is providing. Again in this case also you can think that they will use the database directly but it is restricted and prohibited for the security of data which we have already discussed in the first case. So with this we understand the core functionality or usage of the APIs. Number one is if we want to give access to some other application and number two is if we want to give access of the endpoints or the APIs to our front end. Now this both can also happen at the same time because it is up to us how do we want to expose our APIs. Some applications or some back end basically restricts the APIs to be used through

### Segment 2 (05:00 - 10:00) [5:00]

their front- end applications only and if you want to make them open you can make them open so that other application can also use the same API. Now let's move forward to the type of APIs. The first type of API is called as rest API. If you are a developer you already are using this. Also if you are creating projects you might already have created them or use them in your application. Now rest basically stands for representational state transfer. Rest is one of those APIs which you will see in most of the application nowadays because of its easiness, it structure and its ability to easily maintain a large amount of data with low volume. So that's why we use rest. Mostly in rest we use JSON which is JavaScript object notation which is a way or a format through which we will send or retrieve the data. It is a easy to use format that's why we are sticking with this for this today's video and we are going to cover this in details in a minute. Also we have some other types that is SOAP. SOAP basically stands for simple object access protocol. This is also one way of handling the data across applications across different platforms and soup basically use XML formats in order to transfer the data. XMLs are replaced by JSON because XMLs were really bulky in nature because in order to create every object or every array we have to mention the attributes again and again which is solved by JSON. So that's why we prefer JSON over XML any day in today's time. But the SOAP or the XML was famous back then. So that means there are lot of applications which are still using XMLs. Why? Because there are legacy applications. They are built way earlier uh when JSON was introduced and still are using XML. So in legacy system if the APIs are created and exposed using XML that means in order to make our system work we also need to know about XMLs so that we can integrate those APIs into our system also you can use some middleware application where the data will be taken in the form of XML and will be converted into JSON and your application can use that data afterwards. So that's why if you are working with a legacy system, it is preferred to understand the XMLs also so that you can convert them in JSON or you can work them without converting them as well. So after so let's jump to the third one which is GraphQL. So GraphQL is also used widely across many applications, many platforms. So the basic thing in graphql is graphql basically says that I'll provide a single endpoint only a single endpoint and based on that you can send whichever query you want. So in FE from FE side we will not hit multiple endpoints but we will send a request as a query that's why the graphql stands for graph query language. So GraphQL also have a query language that is similar to SQL. In SQL also we have multiple queries from which we can do our things. In this also only one point is exposed as I told earlier and using that only the front end now can send multiple queries and access that particular endpoint and get the data which they want. So this is the core concept of GraphQL. So as I said GraphQL is also present in our today's time also. So there can be a chance that you learning GraphQL and working on it. The other type of API is gRPC. Here the RPC stands for remote procedural calls. And for G some may say that G stands for Google because it is created by Google. But it is GRC CP remote procedural calls only. So instead of using XML and JSON, we have a new format here which is called protocol buffers. It is very much efficient than JSON and XML combined. So that means the size of protocol buffers are usually very small than XML or JSON. So that will enable the data to transfer faster. So because of this only Google created this and uses this. So this is small in size and faster to transfer. In today's applications where we have microservices, right? So in microservices this is our entire application and let's say our applications is divided into multiple applications which is combining the data of their endpoints through each other. Let's say these are the connections and through this they are going to provide the actual API to the outer world. Now for this communication between these microservices we often use gRBC. Why?

### Segment 3 (10:00 - 12:00) [10:00]

because internally at least the communication should be faster to provide the relevant information in a low latency. This will also help us having multiple microservices and having various kind of communications between them before giving the actual data to the other application or the front end. Now let's jump to the last one in our list today which is websockets. Websockets are also used in today's time in today's application for various purposes. For every notifications if we see websockets are used in order to maintain a chatting stream websockets are used. Wherever you need some realtime connections websockets are used. So its architecture is slightly different from the other services. In other services front end or the other application will place some request to the application and then they will provide the response. But in websockets whenever front end creates a request a channel is created. Now once the channel is established then the conversation can be lead through back end also. Whereas in other forms only front end or the other application which is trying to access the information they send the request and get the request. But in this case since the back end also can initiate the conversation that means it can also send some or the other information by itself. Those information can be the chat or the notifications which is very helpful for front end to get because if this channel is not there the front end have to constantly ask the back end whether there are some new notifications or not or whether the chat is there or not. But once the channel is maintained through websockets, it is easy to navigate message from back end to front end and front end to back end as well. With this also if you have played quizzes on our telescope platform only tlesco channel in which you may see an application which Davincer presents in order to share the quiz with you all you use that application in order to give the responses. Now those responses or the marks are calculated based on the response time and the correctness of the answer. Now those connections are also maintained through websockets. That's why you see many notifications or some GIF or something something. So this is about websocket and with this I would like to conclude this session because it is going to be a long session and it is better to understand these things in parts. So these are the most used five type of APIs which we have. Now in order to understand them briefly in the next video I'm going to talk about restful APIs in which we will discuss the various aspects or the parts of the APIs and also see what are the recommendations and usage of those APIs. So with that this is all about this video. We'll see you in the next one. Bye.