Transcription
Friends, after watching this video to the end, you will learn all the most important things about APIs and information exchange protocols. You will learn to use Postman, work with Swagger and API documentation, and also be able to apply the new HTP client for developers, Connect, in practice. The video turned out to be very long. It is literally such a from Zero to Hero Guide for API testing, working with APIs. In principle, for your convenience, of course, there are time codes in the description, so you can return to this video or navigate directly to the part that interests you. Well, my name is Gashan. I have been writing code for over 8 years, I was involved in the development of GP, AmpliCode. Now I am working on Open de. This is a Russian multilingual development environment for professionals. Videos will be released on this channel not only from me, but also from other strong players in the world. Therefore, subscribe to be at the cutting edge of technology. But before moving on to the practical part, we need to understand the theory a little. The first thing we need to learn today is what an API is. We will understand the basic concepts and principles, and then move on to the practical part. So, API is an abbreviation for Application Programming Interface. The key word here, probably, is interface. In fact, this word raises quite a lot of questions, and at first glance, it may not be entirely clear, but the best interpretation, as it seems to me, is to equate the interface with a point of contact. That is, it is a point of contact of something with something. Well, a basic example from real life that we can take, for example, is some kind of coffee machine, right? So we press a button and get coffee. We don't know exactly what happens inside, how this coffee is made. We interact with the coffee machine through the interface it provided us. And in fact, we encounter various interfaces in our daily lives, we just probably don't perceive them that way. Another quite popular interface that you also, I think, interact with daily is GUI, right, it's a graphical user interface. In fact, this is an interface that allows us to interact, for example, with a computer, with a phone, and so on. So, again, we don't know, essentially, how the processes are organized inside. We have some kind of interface, this time a graphical one, and we can interact with it. Well, returning to API. This is, in fact, an interface for interaction not of a user with some device. It is an interface for interaction between two programs. As an example here, you can take a Telegram bot, you can take, in fact, a large number of applications with which we interact in one way or another. Well, I chose such a simple example as a Telegram bot. For example, the bot wants to know the dollar exchange rate. Well, in fact, the user wants to know the dollar exchange rate, but they interact with the Telegram bot. The bot, of course, will not independently obtain this information from somewhere unknown, right? It will go and ask, in fact, the quotation service through the API. What is the current dollar exchange rate? It will get this information from a third-party service and return it to the user. So, here the bot will interact via API with the quotation service. It is clear that there can be a huge number of such services. A weather service, a news service, and so on. There can be many such services, and we can interact with them via API. And the next logical question that may arise for you is how do programs understand what exactly and where to send, that is, how to get certain information or, conversely, send it. Here, in principle, everything is organized in the same way as with any other interfaces. For example, with an interface in real life, which we talked about earlier. With a coffee machine, we approach it and can choose what we want by trial and error. Of course, the interface suggests to us to some extent, and we will most likely get exactly the coffee we want. Alternatively, in general, we can go and not by trial and error, but read some documentation that may be attached not to the coffee machine, but, for example, to some more complex device with which we will interact. I don't know, for example, a robot vacuum cleaner. So, hypothetically, we will study some instructions. The role of such instructions for an API is performed by documentation. We will look today that in fact, an API can be quite well documented. And this API documentation can be directly converted into the same tools with which we will work today, both in Postman and in Connect, and in any other analogues of these tools. In principle, we can do without documentation, it will be quite difficult, but knowing some basic principles, we can find out what endpoints there are, what information the API provides, and how to interact with it. In general, I think it should now be clearer what an API actually is. And the next question that may arise is, how do programs communicate with each other? That is, it is clear that there is some documentation, but what is described in it, right? And here protocols come into play, and the most popular of them is HTTP. In fact, we will talk about it for the most part today. Here, too, we can give an example from real life. I periodically have to visit other countries, and there I interact with other people. As a rule, this interaction takes place in English. That is, it is some kind of international language that is known for the most part everywhere. It is clear that to varying degrees, but one way or another, knowing English, you can generally go anywhere and express yourself, at least say what you want to eat, right, and where you want to live. Most likely, you will be understood. And if we talk about what a protocol is, then in general, it is precisely that agreement about what exactly we are saying and in what order, right? That is, some basic rules of interaction. And one of the most popular protocols, as I already said, is HTTP. In fact, the entire internet is built on HTTP. Well, that's a rough statement, right, but knowing HTTP, being able to work with it, you can generally interact with almost everything that exists on the internet. In general, any programming language works with it out of the box. If, for some reason, a language doesn't work, write in the comments. It will be interesting to see which one and why. And before moving on, it seems to me important to fix that the API tells us what can be done, and the protocol tells us how it is done. If we talk about HTTP, continuing further, right, why it became such a universal language for interaction. In fact, it is very simple. Text requests and responses are quite intuitive. It is easy to read, understand, and debug what is happening. It is visible what was sent and what was received. It is universal, I have already said that in general. You can get, send, update data, and so on. We will also see this in practice today. Everything works on the request-response principle. That is, we send some request and receive some response in a certain format. So, one second, don't run off and don't rewind. If you liked the current video, please give it a like and subscribe to the channel. YouTube algorithms love this very much. In fact, the client-server scheme is built on the basis of such interaction, right? That is, when we have a separate client application and a separate server application. The client communicates with the server application, sends some requests, receives responses. And this, in fact, is how most of the applications you interact with are built today. I hope that now the basic foundations have been strengthened in your head, and now we can move on to the practical part, namely Postman. In fact, this is a rather classic tool for API testing. It seems to me that everyone starts with it to test any APIs, to interact with a particular environment that exists on a project, whether it's a test or production environment, and so on. Today we will talk about how to create requests, how to interact with some parts of this request, namely parameters, headers, how to import collections from various places, how the request body that we can send is structured, how authentication is structured, and how to work with different environments. Here, I think, the theoretical part will be superfluous, because in practice it will be much clearer, in my opinion. So, let's go, we're moving to Postman. The first thing to start with is installing Postman. It's super easy to do on any operating system. If you just type Postman, you will most likely be redirected to the web version of Postman. In principle, you can work here too, create requests, and so on, but I am more accustomed to working with the desktop version, so I would also recommend you to use it. To do this, just type postman download, and the installation will be super simple for any operating system. After that, you will have this application. At first glance, it may look like a control panel for some spaceship, because there are quite a lot of possibilities here. I wouldn't say that some of them are not useful, it's just that you will probably use some of them constantly, and some of them only occasionally. But in general, we will not cover the entire tool today, of course, but we will cover most of the functionality with which you will have to interact one way or another. Well, the first thing, let me skip some steps now in order to move on to the practical part a little faster. For example, I won't explain what collections are, although here, in fact, a couple of words are enough to say that it's a set of requests that relate to a specific project, for example. And then, within each of these collections, we can create new requests. Well, for example, let's create a GET request that will access this endpoint. And in fact, after executing this request, we will receive the IP address from which this request was made in response. If we open the browser and go to the same address directly in the browser, we will get the same IP address that we received in Postman. That is, in fact, our browsers perform GET requests and can easily render the image that this request returns to us. But in the case of POST requests, for example, the browser will no longer be suitable, and a specialized tool will be needed. Postman will be suitable here. We will talk more about how to configure and create requests, but perhaps before moving on to this part, I think it is also very important to explain how to work with existing collections, because, as a rule, you will most likely come to a project where there is already some API documentation. It is located somewhere, and you will just need to use it, not create new requests from scratch, but use those that were written for you in advance. And in fact, in preparation for this video, I also searched for some public APIs. For example, there are Delovye Linii, which provide their API absolutely publicly for everyone. Everyone can see what it is. And this practice, in fact, is common for many products. If you wish, you can also look at the API of VKontakte, the API of Max messenger, the API of some SpaceX is also publicly available. And you can see what it is. In my opinion, this is also a very interesting practical part, because you can see how an API is actually organized in a large project that really works, with which, most likely, a very large number of developers already interact. Well, let's take and, say, download the Delovye Linii collection. After that, we can import this collection directly into Postman. In fact, there is an import button here. Just click on it and select the file that we just downloaded. Oops. Yes, I just forgot. It was downloaded as a zip file. Let's unzip it. Here we have a JSON file. And let's select it again. Now we have a new collection of Delovye Linii API. And we can see, for example, if you are asked in an interview, can a POST request, for example, delete some data, or can a POST request be used to get some data, you can directly say that, of course, yes, because I looked at this entire collection here. Here, literally everywhere they only use POST requests. There are no other requests at all. No GETs, no DELETEs, no any others. We can discuss how correct this is, but this is how it is organized, for example, in this particular case. And we can interact with all these requests, and separately see what they represent. Well, and then, somehow, modernize them. Another quite popular case is when you have, for example, some Swagger. Again, there is an example of a public Swagger of Petstore. So, here it is described what our service is, how we can access them, with what requests, and so on. And in fact, we can also import information from here entirely into our Postman. To do this, we can take and download a JSON file. It will be exactly the same as in the case of Delovye Linii, but sometimes you don't need the entire collection, right? Maybe you were asked to check just one endpoint, you don't want to export everything entirely, add it to Postman, you understand that you won't need it in the near future. You need to test just one specific request, and for some reason it's not working right now. Well, for example, this API find by status, right, that is, find a pet by status. We can execute it, first of all, right here, right? But if we still need to do it in Postman, that option is also available. Well, let's, for example, choose some status, available, right, and click execution. We see the URL by which this request was made. We see the response that came back to us, a 200, meaning the execution was successful, the request was successful. And we also see what was returned to us, what pets we have for the status that we chose. How do we export this request to Postman now? To do this, we can use the import functionality directly from curl. That is, again, we copied the curl that we had here. We go to Postman. Here, let me click import in my new collection. And, in fact, here, as you can see, you can paste curl, right? That is, what Swagger gave us, we can take and paste it here without any problems, and our request will be exported. We immediately see here where we are addressing and with what parameters, right? We will talk about parameters a little later. And we can choose which collection to import this request into. Well, yes. Well, let me import it into a new collection. And as you can see, all the necessary information has been pulled up here. We have pulled up, in fact, the request parameter. This is the status with the value that we chose in the Swagger interface. We also have headers, right, a set of some default headers that are hidden here by default, and one header that we explicitly set with the type that this request accepts, right, in our case, it is application JSON. And now we can execute it right here. Let's execute it, let's see what's here. The response will be the same as what we had in the browser, right? So, you see, the request was executed in the same way. A 200 status was returned, it is visible what and for what period of time it was executed. Well, and the response itself that was returned to us, we can also examine in detail in JSON format. Also, if necessary, we can convert it to another format, but this depends on where you want to use the information that you received from the endpoint. There are also situations when you have no documentation at all, right, I don't know, for whatever reason, but you need to check a particular endpoint. This can also be done. In fact, I've resorted to this a couple of times, precisely when I was developing tools for interacting with a website, a service that did not provide any public API. That is, we had a web interface there, but I wanted to interact with it not independently, but specifically so that a Telegram bot would interact with it. And therefore, I had to figure out myself where exactly the requests were made, and with what parameters, and so on, in order to implement this logic in my program. This can be done using developer tools, right? So, for example, in this case, well, let's open the same site in the browser's developer console, right, in the dev tools. And here we can, in this particular case, pay attention to the Network tab. Here we just executed this request. In general, let's execute it again. And we will see that this request has appeared in our console, and we can see what it represents, right? Again, the same as in Postman. These are the headers it had, with what body it was sent, in fact, what it returned to us, what its response was, and so on. And copying this request into Postman looks similar. That is, here, using the browser's functionality, we can copy it in curl format. Well, and then, naturally, everything is the same as we did before, we take, copy it as curl, and paste it directly into Postman. And the result is the same as what we did in the previous step. Of course, it's quite easy here, but if we open some other site, let's open, for example, Openbe, open the developer console, go to the Network tab, and reload the page, we will see how many requests were executed here. Yes, and we can also manually track what exactly happened, which resource the site accessed, to find the endpoints we need. But we can also, in fact, automate this process if we really need to view all requests in a slightly more pleasant way, so to speak, and without the chaos that appears here when a particular site continues to load some resources and execute new requests, we can redirect all this traffic to Postman. To do this, in fact, there is this little thing called start proxy. It allows us to intercept traffic, right? So, we can do this either by setting up the proxy manually, right? I've done this a couple of times, in fact, but I've more often used interception through the browser, because it's simply more convenient. You take, install an extension, click Install, add the extension, and that's it. Now we have this Postman Intercept tab. Now we can launch it. It will ask us to log in. Let's do that. And now you can just click the Start Capture button, reload the page here, return, open the plugin again, see how many requests it has intercepted, stop it, and open Postman. And now, in fact, we can immediately see all the requests that were executed, see with what parameters they were sent, and so on, and then interact with them. Well, in my opinion, it's more convenient, right, than transferring each request manually, if, for some reason, we need to intercept traffic in this way or study an API that is not documented. A small part from the start. We immediately talked about how to interact with existing API requests that you might have on a project or you might be asked to interact with an existing API that is not documented. This is, in fact, the simplest example that we have already looked at. Let's suggest, further, so that we don't make up requests and so that they actually work, we can use this Petstore, which is already available. And here, for example, there is a POST request that allows us to create, apparently, a new pet. Since we don't want to copy directly now, we want to create it manually, let me just open this request side by side, and we will try to repeat it directly. In this case, it is a POST request, so let's choose POST here. Next, we need to specify, in fact, the address to which we want to address. Here we only have /api, but in fact, there is also a base URL. And we can observe this base URL here. It coincides here with the URL where the /api is located. Let's copy it, and leave it like this. Here, as you can see, the request has not been executed correctly yet, because this is not the full address that needs to be specified. In this case, we also need to supplement the URL with this /api, which is indicated here. It will allow us to create a new pet. There are no parameters in the request itself, but there is a request body. This request body, in JSON format, describes what our pet is. Well, let's copy, in fact, the body. And the body, as you understand, can be specified here in the Body tab. Here we can choose the type of our body that our request will have. In this case, raw will work for us, right? That is, we will transfer the information we want for our pet in JSON format. In addition, there is also form data and, for example, Form URL encoded. It did not fit entirely here because Postman is not fully open. In fact, this format is used with forms, as is this one. The only difference is that here, it's just key-value pairs. In the case of form data, it can also be some binary information sent along with the form. For example, if you are registering and attaching your avatar to the form, then Form data will be used, and the data that will be sent will be divided into some chunks. In fact, in the case of binary information, we can send a file directly. In this case, we can choose from our machine. GraphQL will not be considered today. And raw. Accordingly, we have specified here what the body of our request is. And now let's try to execute it again. As you can see, now instead of an error, we are returned a 200 status, and we see that our pet has been created. Now let's look a little at the request parameters. For example, we have already looked at the case with find status, we had a request parameter, but let's try to reproduce it. We already see here what curl was sent. And in general, let's open our collection to the maximum for now and create in the collection. Ah, yes, here's the only little thing. In this case, I modified an existing request, and Postman doesn't automatically save everything. You need to explicitly press Commit for the request to change. Well, in this case, since I changed my old request here, let's call it a POST example. Well, never mind, I think. GET, you can reproduce it without any problems, if anything. We wanted to create a new request, right, let's create it. This will be a PUT request, right? This is a GET, right? Let's do it again, this is a GET. In fact, the parameters we have are status, right? We see it here, we see what type of parameter it can accept. Accordingly, this is the status value. Well, for example, let's try Sold. We can describe the description optionally, if we want. Well, in this particular case, there is a description. Let's copy it directly from here and paste it. We don't have authentication yet, but we will fix it next. As you can see, I again need to specify, in fact, the base address to which we want to address. We will look a little further at how this can be moved to an environment variable. Well, we have this for now. Let's copy it. Well, yes, let's do it directly from here, since we have the full address up to the first slash. It seems everything, there is no body here. Yes, let's execute it, let's see what we get back. Method allowed, that I forgot something. Everything is correct, yes, I forgot. Find by status, I didn't copy it completely. We send again, and we get back, in fact, all our animals, sorted by their current status. Further, another important point is authorization. Here in Postman there is a special section for authorization. We can choose here what type of authorization is used. There are actually quite a lot of them. You can choose basic authentication, that is, when it's just by username and password, you can use a token, that is, the token is somehow generated on the backend and issued.
Well, after logging in, for example, a token is issued. Then all requests that we make to the service are made with some token. Well, maybe it's a GVT token and so on. There is AOS, yes, that is, when we have authorization through some third-party service, be it Google, Yandex, GitHub, and so on, and so on. Well, probably, this is the most popular. But there is also AP, which is also used. I heard that it is used in various marketplaces, including for accessing the API when you don't interact directly with the site, but precisely through the API. And in general, we can specify here what kind of authentication we have. Well, let's say, let's choose that we have some token, and I will write random values here. Well, actually, it's complaining here that this is a value that should be set as an environment variable, but we will talk about them a little later, so let's not pay attention to it for now. But after we have specified the authorization here, the one that we use in the service, we can then see that this authorization will indeed be used in the request. It will be attached to the headers. Actually, headers are precisely one of the components of the request, but by going here, you will see absolutely nothing, because here, as I have shown before, there are hidden headers. And here, besides the default ones, well, for example, user agent, that is, this is like the device from which this request is sent. That is, when we interact with any program through a browser, here in the user agent field there will be something like Google Chrome, Firefox, Safari, and so on. If, for example, the request comes from Open, then the user agent will be Open. Yes. And here, besides these default headers, which are present in almost all requests, we can also find our own, which we set manually, it is authorization, and, actually, here is its value. Depending on what type of authorization you choose, of course, this value will also change. So, we have talked about parameters, we have learned how to configure them. We have also talked about authorization and headers. That is, you can generally use it without authorization, for example, by specifying a and then manually writing what our authorization is, with what value. It's just more convenient to specify it here, as a rule, rather than directly in the headers. We have also talked about the request body. We can also talk a little about scripts. Actually, Postman allows us to perform some operations by describing them in JavaScript, either after the request or before the request. We will talk a little later about the fact that personally, as a backend developer, I find it more convenient to do this not in JavaScript, as in this case with Postman, but in Kotlin, yes, it is close to the language that is my base, which is Java, and to describe some actions that I need to perform or build some request chains there, it is much more convenient. But if we want, we can also do something here, for example, let's print something basic. I have specified a pre-request action here, and a post-request action in the post-request. Now, if we execute this request, we can see in the console, yes, here at the bottom there is a set of elements available in Postman. This is, for example, the console. If we select it, we will see here that before and after the request execution, the actions that I wrote were indeed displayed. In fact, the practical application of this can be somewhat different. We can, for example, make some delays here, yes, that is, say that you wait a little before executing the next request. Or we can log some really useful information here. That is, get the environment variables that have come to us, or something else, to then see that everything in the console was executed with the values that we needed. And actually, it seems that regarding the request, in general, I have told you everything I wanted to. Yes, there is also a settings tab here. Here we can configure more precisely what our request is, that is, the HTTP version used, whether to use SSL certificates, and so on. We will not cover this part today, but in general, know that such a possibility exists. Probably, the last thing I wanted to talk about, regarding Postman, is environment variables. We have seen in our two requests that the address we are accessing is duplicated here. Well, most of it, yes? That is, the specific endpoints change. And actually, there can be several such addresses. That is, there can be your production environment, on which everything is based, where users actually go. It can be some test environment that you want to access to really test some new functionality. It can be some local service that you have set up and want to access. And all these values with the same parameters, with the same authorization, with the same headers, body, and so on, need to be executed. Of course, we could create many new requests and collections, but no one does that, everyone uses environment variables. How does it look? Well, let's actually copy this part and go to the Environments tab. Actually, here we can create new variables. There are global variables, and there are separate scopes that you can create. Well, in this case, I created a separate test scope. Let's delete it for now and create a new environment. For example, this will be our production. The environment variable will be the URL, and its value will be like this. Now we can use this environment variable in our requests. Well, to make it interesting, let's immediately create a second environment. This will be our test. Actually, here we will also have a URL variable, but its value will be, let's say, test. Actually, let's probably do it like this. Test. Now we can use these environment variables in our requests. Well, let's go back to our collection, open this request. And here, instead of this part, instead of this part, we will specify, actually, our URL that we just created. And, as you can see, I have written it now, and it's complaining that it doesn't exist, because no environment is currently selected for this request. To select it, you need to choose one of those that we just created here. If we choose production, then, actually, it is immediately visible what it represents. Now, if we execute the request, then, as you can see, I made a mistake here and specified a double slash, but it is visible that the endpoint that we wanted was substituted. Let's remove the extra slash. And, actually, everything is correct here. But it's actually better to change it here, remove the extra slash, because it will look much more pleasant. Let's go here and add it again. If I change the environment to test and execute the request again, we will get not found. But we can see that our request, again, by going to the console, was executed on the new base URL, actually, test. Well, since nothing is deployed on it now, we didn't get any response. Well, and actually, now it seems that I have told you everything about ordinary requests and their creation. Probably, the last thing, yes, about such a feature that if you hover over it, you can see what value is used there, and change it right from here if needed. Sometimes it's also convenient for any environment that is currently selected to change the value. I made a mistake again. Let's go back and remove the extra slash here. The last thing, probably, concerning Postman, that I wanted to talk about today, but only briefly, is about complex automation and building request flows that can be executed. That is, as a rule, we don't have a situation where we execute some single request and that's it. As a rule, it's usually some chain of requests, and we want to test some complex scenario. That is, for example, we want to get a token, by which we can access another endpoint. After that, use this token for a new request, and use the result of the new request further down the chain in some subsequent request, for which the data that we received from our last request will be used. Such a possibility exists. And here in Postman, it is called flows. That is, you can build a flow and automate this process of working with the API. The story is actually very interesting and very large-scale. That is, a lot of automation can be done here, and setting up this flow is indeed complex. In my opinion, this is both a plus, yes, that you can essentially do a lot, but it seems very complicated. That is, here I need to dive into the UI so much. I have set up similar automation a couple of times, but the experience, in my opinion, is not pleasant. That is, if you are really constantly engaged in testing, I recommend you to delve into this topic and study the basic aspects. Perhaps I will even record a separate video on this topic later, if you are interested. However, since I am mostly a developer, I don't really resonate with this kind of diagram building. And for this reason, for testing such complex request chains, I prefer Connect. At this point, let's go back to the presentation that I have. There are only a couple of slides left here. Actually, to conclude with Postman, as you noticed, the tool is simply amazing. What I showed you, that you can create requests manually, import them from different places, and sniff the traffic that comes to your browser. These are, well, indeed, killer features. And the skill of using Postman, in my opinion, is mandatory. But Postman is inferior, well, personally for me, yes, but, as I already said, these advantages that Postman has also lead to some limitations. That is, in this particular case, in the case of Flow, in my opinion, the UI slightly limits me specifically, because I really need to delve into this UI and understand what it represents. I know how to write code, and I would like to write this code manually. Or maybe not write code manually at all, but get an agent to do it. That is, if the agent has an example of this automation, you can ask the agent to implement not only the implementation that the agent itself writes, but also to implement checks on the tool if there is a specific DSL for this. And this logic, which often has to be done, about which I told you, about the example with getting a token, then using it, then using the result that came in the next request, it is very easy to describe precisely in an imperative programming language. That is, when you explicitly say what needs to be done and how. Here, we are smoothly transitioning to the final tool for this video, to Connect. Again, I will briefly go over what is available in Connect. There are basically all the capabilities that we looked at with Postman today, yes, that is, creation, importing requests, using parameters, headers, request body, authorization, authentication is supported, of course, working with environment variables, but there is something that Postman does not have. That is, it is adapted specifically for developers. It is integrated, first of all, directly into the IDE. There is tool support. I will show you today how you can get it. And describing these complex scenarios, in my opinion, is much easier. And what I told you about AI and capabilities. You can essentially just take your agent and point it at the code you have for interacting with the API. By analogy with Postman, let's start with where to get Connect. Well, the simplest way, type Connect. And the first link we can go to in Google is the link that leads to the Applicode website. Initially, Connect was developed as a tool for Spring developers who write in Java and Kotlin. But the tool turned out to be so cool and so interesting even to those who don't write in Java and Kotlin, that now it can be used not only in Spring projects, but in any projects. But the client itself is still supplied with Applicode, that is, you cannot install it separately, for example, in WebStorm, in PHPStorm, and so on. You can try to install Applicode, but alternatively, you can also use Open IDE. In Open IDE, this HTTP client is built-in by default. That is, right after you download and install Open IDE, all capabilities will be available. Today I will show you how to use them. Accordingly, you can study the basic capabilities here on the landing page, see what they represent, and so on. And the coolest thing is that you can also look at the client code itself, because it is open-source and available on GitHub. That is, in theory, you can even do all the requests that we will be doing today, we will be executing them in the IDE, because, as I have already noted, Connect has quite serious tool support, but in fact, nothing prevents you from simply executing these requests from the terminal, as you execute, for example, curl. And to summarize, if you want to use Connect, you can either install Applicode in your IDE, or you can simply use Open IDE. There is support for many languages, including Go, Python, Java, Kotlin, and so on. And this type of client is already built-in by default. Look, I have opened a project. Absolutely any project can be. We will look at deeper integration further. But the first thing we will start with is precisely the basic requests that we discussed, including with Postman. How does it look? To start writing requests to your API using Connect, you need to create a separate connect script. Well, let's call it something like request demo, for example. After creation, you immediately get several example requests that you can use. Well, actually, here is the very GET request, it will be made to the base address, but we, let's repeat the same example that we used in Postman with getting an ID here. That is, I will replace this host with this. Actually, you can even leave the examples that are here. And let's just write it from scratch. That is, we can just write get. That is, we execute a GET request. And then write the path to which we want to make this request. Here I paste the very address that we used. We click run, and this request is executed right in the IDE, we see here that the request was executed. Then we see the headers that were used to execute this request. And after that, we see the response. That is, we got a 200 status, some response headers, and the body of the request was returned to us. We will return to writing requests manually later, and for now, let's start with the scenario that we did in Postman and imported an existing collection. This can also be done here. To do this, you need to click the button in the top panel and select Postman Collection. Actually, this is the same collection that you can import into Postman, and in general, you can export from Postman to import it here, right? Yes, so actually, we didn't look at this in Postman, that all the collections you create, you can also export them to share with another team member who uses Postman, or to import into another document. For example, I again use the same business lines API and import requests directly into the current file. And, as you can see, all my requests have been imported here. As you remember, we only had POST requests there, and we can see them all here. There are actually a lot of them. And in this case, the file becomes simply huge. But we can also view them in this form. That is, we can view them purely by URLs, by which interaction occurs, and navigate to them if necessary, and execute a specific request. But I will probably roll back all these requests from the business lines API for now. It is clear that we can execute them without problems. There is also support for importing from curl. Well, that's what we looked at. Again, let's click import from curl. Here I will paste the same curl request that we analyzed in Postman. That is, here we have a GET request to an endpoint where sorting by status with a specific value is performed. Click OK. And the request is imported. Here we can immediately, if we want, change the base URL, for example, import it into an environment variable. But we already have a request ready, what it represents. That is, again, GET. Here we specify the address we want to access. After that, we have the query, that is, precisely the parameter of our request, and its value is key, status, and the value is available. And everything, accordingly, the request accepts application JSON. Let's execute this request to check that it also works. Everything that was returned to us, we can see here. Again, the JSON here is very large, and it can be viewed separately by opening, actually, the file itself. Well, here, of course, the formatting of this JSON is in one line, but it can be formatted without problems, and you get 7,000 lines, which can be expanded by nodes and you can see what each of the elements represents. Well, further, you can use all the actions that we are used to, such as multi-selection, cursors, and so on. I made a separate video about this. If you don't know how, and don't yet know all the IDE capabilities, in terms of selection, navigation, and so on, then I highly recommend watching it. Next, let's look at the example we have with a POST request. As you can see, here I have already, when we created the file, a POST request was generated. Here, we can also specify what type of body we are passing. In this case, it is JSON. And, actually, the body itself is passed in the form of this JSON. Actually, here, let me find myself in an application that is already running. We can access it. And here, if we look, for those who are well acquainted with Java, I think there will be no problems. Those who don't know Java, in general, can skip this fragment in terms of not quite understanding what is happening. We will just look at the specific implementation of the service we are interacting with. This is not always necessary, yes, if you are just testing an API. But in this case, since we are closer to development, most likely, I developed this service myself and now want to check how it is structured. But in general, nothing prevents you from using Connect for testing external services and so on. Here I have this product controller. Accordingly, it allows me to create new products in my application. That is, I have some list of products. And here there is this create endpoint, which actually expects POST requests. In general, I can write this request manually. That is, I know everything here. I know that I have localhost 8080. The application is actually running on it. I also know that my address is Products, so here, in this method, I can write products. Then I actually know that JSON is expected. Let's see what JSON is expected as input. Create product DTO, so here I will have name and price. And I can generally write name here myself, and then put a comma, write price here and specify the value 123. Well, let's see if I made a mistake here, it's products like this. And let's try to execute this request. Great. I managed to create a new product with the value. It was assigned an ID, and the price we specified. Everything is great, but, as a rule, in applications, these JSONs are quite complex, and it's not always desirable to write them manually like this. And this is precisely the moment when integration with the IDE really helps. That is, in the case of Postman, we would have to manually go to the IDE, see what the DTO represents, copy its value, and then create a similar JSON in Postman. In this case, we can go to our product controller. And, well, to make the example identical, let's create a request for the same endpoint right here. I click on this icon and click generate request in Connect. And a new request is immediately created, which contains the correct URL, immediately the one that is used in my application. The correct header is immediately set, and a JSON with the values that I expect as input is generated. Indeed, this integration of the client with the IDE allowed us to see what the DTO that is expected as input represents. And we got the JSON right away. Another way to create requests is to use this plus sign here. Here we can choose the type of request we want, yes? For example, it will be delete. The method is immediately scaffolded for us. And here we can further describe what it should represent, what headers, query parameters, and so on, we expect for it. The coolest thing is that besides all these available requests, we can also open this Applicode IDE Designer panel and here, too, drag and drop all these methods that were in the top panel. That is, we want a patch, we drag patch, the code is scaffolded, which we can then describe what our patch request should represent. And the killer feature for those who write in Spring, there is integration with all endpoints. That is, for some reason, this integration is only available in the Generate menu, which is available by Command N. There is a request for an endpoint, that is, it is not in the Applicode designer, nor in the plus sign. Perhaps it will appear someday, which would be logical, but now it is only available in requests for endpoints. And here all the endpoints that exist in the project are immediately displayed. That is, we don't need to go and search, as I did at the beginning, for a specific controller. If we know the path it is located at, then we can start typing products here, some by IDs, and the entire code needed for this specific request will be immediately scaffolded. In general, I hope that there should be no more questions about writing methods manually and this generation. In general, I think that with generation, creating simple methods like GET, POST, DELETE, and so on, for existing endpoints, for importing from existing collections, there should be no questions, because here it is done essentially automatically. Probably, the most interesting part is precisely working with variables and what I told you about, creating complex requests, chains of requests, yes, where we can use the result of one request in the next request. Let's move on to this immediately after looking at working with variables. We saw here that I declared this host variable here. And, as you can see, it has a specific value assigned. Actually, well, we already know that there can be several values declared for the host. Currently, no environment is selected here.
environment, although in reality, as you can see, I already have an environment def, there is an environment rancher, there is an environment prot. We can switch to them in this way through edit, of course, not through select. And this is, in fact, a regular file that lies in our project. And this file describes specific keys for different variables. In the case, respectively, with the dev environment, our host will be like this. In the case of rancher, the host will be the following. And in the case of production, it will be absolutely different. And in order to use these variables here, we need to write this simple construction, which I actually forget periodically, but examples save me, if anything. If you also forget how to use variables. You can go to the advanced example in this way. And here there will be an example of using an environment variable. That is, we need to specify its name, after that specify its type and say that we want to take it from the environment. Let's replace our host. And now the value for our host will be selected depending on the environment with which we will work. Well, let's choose dev now, check that nothing has changed. For example, we wanted to create a new product here. Yes, let this be test. Let's run it. Well, everything executed perfectly. Now, if we change and choose, for example, Rancher, run the same request again, we will get a 404, because at the address that was described for rancher, absolutely nothing is working now, there is no service. Accordingly, in the same way, we can create absolutely new ones. Right from here, for example, yes, this can be a new environment, and add some new values to existing environments. Well, in general, here we have a JSON file. Even the IDE helps us here with the fact that we need to add some new values. And after that, the usage, respectively, will not differ. We just need to write here that this will be a URL. Well, it could also be a port, yes, but in this case, we had a username string by. And then use this username in our requests. An important part that we also discussed with Postman is authorization. Everything works great here with authorization too. We can go to examples. And there is a separate section authorization. In general, various types of authentication are supported here, which we also saw in Postman, and basic authentication, that is, just by login, password, and token authentication, yes, that is, it can simply be passed in the format, for example, through the request body or it can also be specified in the headers in the same way. Or here, we are demonstrating in exactly the same way that you can specify a token with the value Bearer, yes. Well, also a basic story with authentication and access by token. All these requests also work, in fact. Let's, for example, choose this authentication and run this request directly. And it returned successfully, yes, that we really managed to get all the necessary data. Examples also include examples of uploading and downloading files. Various formats of what files we can download and upload are supported here. We also discussed that in Postman there is precisely the ability to upload files using Form data, yes, and there files were uploaded using multipart as well. I told you about this, that is, in separate parts. In this case, we can also describe that our file upload will go in several parts, yes, that is, we upload some text parameter, we upload a file, all this goes away, for example, from one form, yes, we can emulate this in our connector. Also in examples, we can find examples of working with file uploads and downloads, yes? That is, we can upload files using a multipart request. Here we describe separately the part that is not a file, and we can pass the file itself. And since we are essentially using Kotlin code here, we can take and directly use some language constructs. That is, for example, this file is an imported Java IO file. Well, that is, for me, as a Java developer, this is literally, just take and do whatever you want. With the API that you are already familiar with, with the language API, I mean, yes? That is, you already know that the language has certain capabilities, and you can use them here without problems, that is, take and upload files from your file system in this way, yes, and write a loop, for example, yes, we will also move on to this. Or here, use the readBytes function, yes? That is, if you are at least a little familiar with JVM languages, then, in my opinion, it will be super easy to get started. There may be some resistance at first, because I also had some at first, when I looked, I thought: "Damn, it's a bit difficult." That is, if we talk about HTTP from Intel ID, where or just the basic HTTP itself, yes, then requests are described literally as an HTTP request, yes? Here, however, it is a small DSL on top, but it is quite close to what an HTTP call itself represents. Also in examples, you can find settings for SSL certificates. This also, in my opinion, is a more advanced story, but everything can be done here too, if you need to pass various things for interaction in your API, if you need to use these certificates and so on for interaction with your API. This client also allows you to do this without problems, yes? That is, we can configure the client separately here and configure its individual parts using a higher-level, higher-level DSL that we have, yes, using this configure client. I haven't mentioned the story about all the examples we've looked at, yes, let's go back to the very first example, here we have a pure request and nothing more. In fact, since we are testing APIs, we don't always want to check everything manually, yes, we can take and describe what we expect to receive. That is, in this case, here is exactly the same request as we had. For example, here we want to create a pumpkin with a cost of 158 some fictional units, yes? And so that we don't have to manually check every time that we really got the desired value, we can write assertions. That is, we can write that in this case we expect that the name will be equal to pumpkin, yes, and that the price will be equal to 158.9. And that we will also have in the response the value of the field with the ID. not equal to null. And here we haven't selected any environment yet. Let's choose the test environment. I also have configured the one on which the service is currently running. Separately, what I haven't mentioned yet is that all these requests that we describe here in the form of code, we can improve them further by turning them into tests, in fact. That is, what we did before. We executed this request, created a new product with the name test and a price of 123. And then we manually went and checked that this request was indeed executed. And we got the values we expected, that is, the same name, the same price, and at least some ID that was set. We don't know exactly which one will be set. It's set by the database. But that our new product's ID was returned. Instead of doing this manually every time, we can use this construction called "then". And here we can write an assertion, yes? That is, just like in tests, we can take and write that we assert Z. Import the function directly from the Assertj library and describe here what we expect. In this case, we can also use JSONPath. It is natively supported here. And read, for example, some string. And this will be, accordingly, the name. The IDE also suggests a bit here, but not entirely correctly. And here we will have equal to test. Everything is correct. And there can be several such assertions here, yes? That is, we have described that we expect with the name. Let's try next, so that the IDE suggests. Price. Everything is correct. 123. And the last thing we need to check is that we will get an ID. Yes, here the IDE starts to invent something incomprehensible. And this will be read long. Well, almost correct. Here it is not. Well, and obviously, we just wrote this manually. In general, we can also ask the agent to generate the same thing, by adding the examples that we already have here to its context. And it can write new scripts quite well based on them, so that you can, for example, take the new endpoint that the agent generates and click through it manually. And not just click through it now, but also later. That is, you essentially have a self-test like this. Let's run it, check that it really works. Oops, only, yes, here I forgot to select the environment. This will be def. Let's restart. Yes. Well, and here it returns not an integer. Ah, well, yes, here I made a mistake, that the price is not a string, of course. Therefore, let's make it read double here, in theory. Or just read, yes? Let's. This will be just read. And here we will describe further. Well, as you can see, because this is just Kotlin code, we can easily use all sorts of things like this, which again, perhaps are not familiar to those who see it for the first time, but for those who are well acquainted with Kotlin, this is a very understandable story. And again, with agents now, it seems that agents could write this without problems, yes? And since this is a double, yes, 123.0. Let's add 123.0 here and finally get a green test. Great, yes, our test passed. And now, if something breaks, we will definitely see not only with our eyes, but also there will be a big assertion right away that something didn't work out. Finally, the last part that I want to show you is using the result of one request in another. Look, in this case, I have an endpoint, let me find it. This endpoint. Orders, order id lines, yes? That is, here we have an endpoint for adding new products to an existing order. That is, to interact with it, we need to specify the ID of some order. Previously, this order, we must create it, yes? Here we have such an endpoint create. Well, let me create a new request for it, yes, and the value that I get here, well, let it be customer ID1, C ID 1, the value that I get for it, that is, I will be returned the ID of this order, I would like to use it further. I can do this. To do this, I just need to write "order ID". In this case, this is order ID and write "by". Everything, now the value that we get after we execute this request will be saved in the variable Order ID. And we can use this variable further, yes? Let me go back to our order controller. Here, for this endpoint, let's also create a new request. Here, an order ID is expected. And here, directly in the path parameter, I can take and pass Order ID. The value that I will get from the request above. But in fact, when we execute this request, I will not get a specific ID, yes, I will get the entire request body, and therefore I need to extract from it, in fact, only the necessary part that I need for the request that follows. Here, therefore, we can, just as we used JSONPath before, write "read long" and specify here that we are interested in the ID through a dollar sign. Like this. Everything, now from my entire request, only the ID will be extracted. And then this ID, which will be saved here, will be used in the request to create new items in our order. Well, and obviously, we can then use this request for, say, five, one. What's coolest is that if the value hasn't been calculated here yet, and we now execute this next request, let's choose here that it will be def, and execute this request. If I haven't messed up with the IDs anywhere, then in general it should execute. And now let's try. We have two requests. One depends on the other. Let's call the first one first. A new order will be created. As you can see, it has been assigned some ID. And now this ID is stored in this variable. Now we can call the next request. And here, instead of Order ID, the value from this variable will be substituted into our path. Let's call it. Here we couldn't reserve this quantity of products. Apparently, for this product that we chose, two. Apparently, there is a smaller quantity, yes, unable to reserve product. Apparently, there are fewer of them available. I'm just not going to figure out exactly what went wrong there. I think the logic is clear that the request was indeed executed, as you can see, to the address where the value two was substituted. And this, I think, is simply amazing. But the very last thing we will finish with today is that this entire chain that we have described here can be declared as one large request that should be executed together. What am I talking about? Look, again, we can go to examples. There are advanced examples. And here there is such a story called use case. I decided not to write it from scratch right now, because, as you can see, you can write a lot of code here and write various conditional constructs, branches, and so on. That is, what is happening here? This is one large request, yes? We can even give it a name, actually. Let me copy it from the 12 examples, we will copy it. Generate examples. Paste it here. We can give this use case a name, yes, for example, filling the warehouse with products, yes, it seems that's exactly what's happening here. As you can see, I don't have the host variable created here, yes, so let's just copy this value and declare a new variable. First of all, we can, again, look at this request, yes, it is visible by name. We can also view it hierarchically, what it represents in the Structure panel, that it includes several requests. That is, first, we get a list of cities using the GET method. And here, pay attention, if we previously extracted an ID, that is, some primitive type, we can extract not only an ID, but also work with complex structures, for example, with some DTO, yes, it is quite simple here at the same time, yes, a DTO that contains just an ID, yes, but it is still a separate object, it is a city, yes, and we save this city in a data class. We have a list of such cities. We then get a list of products, yes, that is, using this request, again using JSONPath. And after that, we iterate through all cities, iterate through all products in these cities, and execute POST requests for all elements with which we will interact. And thus, we fill the entire inventory for all, the entire warehouse, yes, for all cities and all products that we have. Well, here we are generating randomly, that is, these chains can be built absolutely differently, yes? Well, let's try to run it. In theory, it should work correctly even for me, yes. And as you can see, many requests were executed at once. Well, let me sort them by this, 27 requests. That is, for all cities, for all products, these requests have now been executed, and we can all look at them. I would actually like the output here to be a bit more compact, yes? That is, to make it concise now is not possible, but you can navigate through the responses that we receive, yes, or through this wonderful thing that saves our responses in JSON, yes, we can also navigate and in general look at each of the responses in JSON format, like this, what it represents and what product was added to the warehouse in this particular case. Well, guys, I think we've had a super cool video today. We've gone from basic fundamentals, what an API is, to a full immersion in Postman, and then also learned a new tool for developers to test APIs directly from code. If you liked this video, if you have any questions or suggestions for future videos, be sure to subscribe to this channel. Many videos about programming will be released here this year. And if you are just starting your journey or want to become better and better at this, then be sure to subscribe here on Telegram, on TikTok, if you are there. I have wonderful shorts there. And of course, use OpenDE. Now it's the best in which you can write in Java, in Kotlin, in Python, in front-end technologies, yes, it's JavaScript, TypeScript, and so on. In general,