What is API | Bondar Academy
Course: Cypress UI Testing with JavaScript
Module: Working with APIs
Instructor: Artem Bondar
Lesson Summary
In this module, we will explore APIs and how to leverage them in Cypress to enhance test execution by directly interacting with or mocking APIs. What is an API? An API (Application Programming Interface) facilitates communication between applications. A clearer definition might be Application Communication Interface , as it describes how clients (e.g., browsers) and servers communicate through requests and responses. API Communication Clients send requests to a server's API URL. The server processes the request and returns a response. API URL Components An API URL typically consists of: Protocol: Usually HTTPS . Domain: e.g., example.com . Path: e.g., /api/articles . Query Parameters: Key-value pairs, e.g., ?limit=10&offset=0 . API Request Methods Common HTTP methods include: POST: Create a new record. GET: Read a record. PUT: Update an existing record. DELETE: Remove a record. Client-Server Interaction When a client sends a POST request, it must include: URL Headers (e.g., authorization tokens) Request body (in JSON format) HTTP Response Status Codes 200: Success 400: Client error (e.g., 404 for not found) 500: Server error Cypress Testing Cypress can interact with APIs directly or mock responses to speed up tests. While mocking can improve speed, it may miss real integration issues. Cypress can also perform API testing, although it is not primarily designed for it. This module provides a comprehensive introduction to APIs and their integration with Cypress. We will delve deeper into these concepts in the upcoming lessons.
Video Transcript
Hey guys, welcome back. In this module, we will talk about APIs. So how you can leverage APIs in Cypress to speed up the test execution by interacting with APIs directly or mocking the APIs, we're going to talk about all that. If concept of API is something new for you, in this particular lesson, we will talk about what is API, how does it work, and so on. So let's jump into it. So what is API? So API is the acronym for Application Programming Interface. But in my opinion, this definition is kind of confusing, because more clear definition would be Application Communication Interface, because this is literally what's happening. This is how all applications, like almost all applications in the Internet, talk to each other. Clients and servers, they communicate through their APIs. And how it happens, for example, client is our browser and server is our server with database and some information that we need. And clients send the request, server processing this information, and then provide the response. And this is how this communication happens. And this request response happened like thousands times during the user session. It happens very, very, very fast. So let's talk about it in details. How client would know how to access the API? So every API has the URI or URL. So URI stands for Uniform Resource Identifier, or URL, you should heard this term, is Uniform Resource Locator. So both definitions are correct. So this is a unique URL to the resource that you want to reach on the server. And client knows this URL and when some information is needed from the server, client send the request to this URL and get the response. What is important to know that API URL and just application URL usually is different. So you cannot take API URL and just open it in the browser. And the same thing, you cannot just take application URL and send API request to it to get information from it. So these are two different URLs with different paths. So let's look into this example. Let's say our client wants to get information about the articles. And we have two API URLs, so examples.com API articles and examples.com API tags. And when client and our browser want to get some articles and send the request to articles endpoint, server processing this information. And based on this path of the endpoint, which is article, server understands that, hey, I need to get information about the articles. And server doing some internal processing, looking into the articles database, articles table, pulling this information and return it to the client. Or if our client need to get information about the tags, it sends the tags endpoint request and server identifies, okay, this is a tags endpoint, so I need to provide information about the tags. And server routes the request to the tags table in the database and that way pulls the information about the tags. So now let's talk about API URL components, what is consists of. So this is the typical example of the API URL. From the URL perspective, just from the general description, it consists of the following parts. So HTTPS is the web protocol, how we send the request. It can be HTTP, for example, not secure or some older protocols like FTP and so on. But for the rest APIs, usually it is a web HTTPS protocol. Then we have a domain, example.com or anything like that. Then after slash, you have a path and you may have API slash articles, slash something else, slash something else and so on. So the path for the URL do not have any limits. And then after the question mark, you have a query parameters. Query parameters come with the key and value pairs. For example, limit equals 10, this is one key and value pair. And then the second value pair is offset equals to zero. And again, you can have unlimited number of those query parameters, which are separated by ampersand sign. And it can be all part of this URL. When we talk about test automation and interacting with the APIs in the framework, so I would slice this into this. So the URL which includes domain protocol and part of the path can be considered as API base URL. So you define this URL as your constant in the framework, somewhere in configuration settings. And then the path to the resource, which is your variable that you put inside of the test, we consider as endpoint. So based on this endpoint, we know which exact resource we want to reach on the API. And then after the question mark, we also have query parameters that we can define as a part of our request URL. So let's talk about API request method. There are a bunch of those methods, but there are four main methods that are used like everywhere. And those methods are the following. So POST request is when you want to create a new record on the server site. When you make a GET request and GET method, this is when you want to read a record from the server. So you make a GET request. PUT request is you want to update some existing record on the server. And DELETE request is obviously just to delete the existing record. And you probably heard about acronym CRUD. So it stands for Create, Read, Update, and Delete. So CRUD operations, these are four main typical API operations. So now let's talk about client-server interactions a little bit in detail. So let's say the client send POST request to the server. What else coming with the POST request? With the POST request, this absolutely have to be the URL. This is a must component for any API request. Also, POST request may have headers. And usually headers include the type of the data that we are sending, compatibility type, in our example, it's application.json, and authorization token. So most of the API endpoints out there in Internet are secured. So server should somehow protect itself from unauthorized request. And this is how it does. So normally, you provide authorization header with some secure token. And then server checks, okay, is this token correct or not? And if it is correct, then server allows this request to go through. And for the POST request, you would have a request body. Request body come in the form of JSON object with the key and value pairs. And this is the information that you want to create on the server. So in our example, we're creating a POST request to the tags endpoint. And we want to create a new tag with the name hello world. And after server receive this request, if the request process successfully, it provide response and response has two values. So first of all, it's status code. When the response is successful, when the request is successful, usually it's gonna be 200 status code that confirms that request was successfully. And sometimes it can be response body as well, but optional, not necessary. Especially for the POST request, response body is not always. When you send a GET request to receive some information from the server, then yes, you will have a response body in the form of JSON objects. Now let's talk about types of the HTTP response status codes. So first of all, 200 level status code, it means that request was successful and server was able to provide successful response. And there can be different types of status codes, for example, 201, 203, 204, and so on, all of them meaning that it was successful. Then the next group of status codes is 400 level status code. It means that something was wrong with their request. It means that client send the request but server did not accept it because something was incorrect in their request. It could be, for example, incorrect URL, or it could be incorrect request object, or it can be incorrect header, or maybe incorrect authorization token. So something in the request was wrong, and status code can tell you about it. For example, if you get a status code 401, it means that something wrong with authorization, server did not accept it. Or if 404, I think you know this status code, a 404 error means that this resource simply does not exist. The URL that you're requesting, the endpoint that you're requesting, is not correct, it's not available on the server. So that server is responding, hey, 404, I don't have this type of endpoint. And the next level of the errors is a 500 level status code. It means that something happened on the server. It means that when you send the request, request went through, and server started processing this request, but then something happened on the server side. Server was not able, for whatever reason, process this response, and it's responding you with 500, sorry, I was not able to process it. In such scenarios, you need to dig deeper into the server side, into the logs, understand the details, what went wrong, and do some kind of debugging on the server side. So this is the most difficult type of the error, and usually you will need the help of developers to help you analyze what went wrong. All right, moving on. Another example of how would you normally see on the application, like visually in the browser, what you see and what is happening in the background. So imagine on the left you have a browser with username, password, and login button, right? So then you type john123, welcome, and click on the login button. And when this happens, browser sends API request to the server with a JSON object, with the information that you entered in the browser, username john123, and password is welcome. And while server is processing your response, browser, you will see usually some type of loader or spinner or something. It means that our browser just waiting for the response from the server until it will be successful. So server processing this request, if request was correct, then server was provide the response. For example, with the details, first name John, last name Smith, and age is 35. And when browser receiving back this JSON object with this information, you may see in the browser something like this, welcome John Smith, your age is 35. So again, this is just basic example how the data exchange happening between client and server through their APIs. And let's talk about Cypress UI testing. So when you do like a regular UI end-to-end automation with Cypress, this is what happening. So Cypress interact with your web application, for example, clicking on some button on filling out some form. Then web application send request to the server based on this interaction. Then information coming back, your UI is updated with some changes, change the screen, new data, and so on. And you validate this in Cypress one more time, and you repeat this process again and again. And this is how we normally run our functional end-to-end integration testing. And this process is actually fine, but it has kind of a disadvantage that it is kind of slow and can be flaky, especially in the complex scenarios. What you can do instead sometimes, you can improve your scenario with this way. So you interact with your application using Cypress. And when application send request to the server, we intercept this API request by Cypress mock. So the request never reach the server, and we provide the response that we want to be displayed in the web application. And then Cypress then makes the validation of this on the screen. So this type of testing speeds up execution like a lot, because you're not spending time on actually sending the request to actual server and waiting for the response. Everything is happening in the close loop between the Cypress and the web application. But there is some disadvantage with this types of testing, because you technically is not making a full integration test in this case. And if you will mock everything for your web application, you may miss a defect of real integration issue when the server actually process the data differently, not the way how you decided on the Cypress mock. But this trick is very useful when you need to test, for example, some H cases. Or you need to set up some complex test data, which is difficult to set up. But instead, you can set up the mock for that and test this difficult scenario. So in this module, we also talk how to do this. And also in Cypress, you can test APIs directly. So you can remove the browser completely and just send request to the server. Cypress will get the API response, and you can make validation of the API response directly. And this is what called API testing. We will not heavily do API testing with Cypress, because Cypress is not technically designed specifically for API testing. But it can do API testing, and we will also cover this in this module. All right, guys, so this was introduction to the APIs, how APIs actually work. And in this module, we will dive deep in details how to use Cypress and interact with APIs using Cypress. All right, that's it, and I'll see you in the next lesson.