Introduction to APIs | Bondar Academy
Course: Playwright UI Testing with TypeScript
Module: Interacting with APIs
Instructor: Artem Bondar
Lesson Summary
In this lesson, we begin a new section on Interacting with APIs using Playwright, which offers robust support for working with APIs. Key functionalities include: Intercepting browser API calls Performing API calls and asserting or processing responses API testing capabilities Introduction to APIs API stands for Application Programming Interface , which allows interaction with a system through defined endpoints. For example, a weather API may have endpoints like getCityWeather and getCityForecast . Types of API Requests The most common types of API requests include: GET : Retrieve specific data POST : Create new data PUT : Update existing data DELETE : Remove data API Request Components A typical API request consists of: API URL : The endpoint to which the request is sent Headers : Includes content type and authorization tokens Body : A JSON object for POST or PUT requests Status Codes API responses include status codes to indicate the result: 200 : Success 300 : Redirection 400 : Client error (e.g., 404 for not found) 500 : Server error Playwright and API Interaction In Playwright, you can: Mock APIs to improve test speed and stability Intercept and modify API responses Make direct API calls for headless authorization This lesson provides a foundational understanding of APIs and how to interact with them using Playwright. See you in the next lesson!
Video Transcript
Hello, guys, and we are beginning a new section, Interacting with APIs. PlayWrite has a very good support of working with APIs. So it can do such things for you as intercepting the browser API calls, or you can perform API calls using the PlayWrite and asserting the response or processing response however you need. You can intercept the browser API response, modify it, and use it later on. Or you can even use PlayWrite for API testing. So all this you can do in the PlayWrite. And about all those concepts, we're gonna talk in this section. And if you are not familiar with APIs or never worked with APIs before, in this particular lesson, I will make introduction to APIs for you. So you will know what API is about, what is it, and how to use APIs in general. So let's get into it. So API stands for Application Programming Interface. It's a kind of a black box that we can interact with, sending different requests to the endpoints and getting the responses. For example, we have this weather API. And this weather API have two endpoints, getCityWeather and getCityForecast. And if we send, let's say, requests to the first endpoint in the form of JSON objects with the city name, let's say city name is New York, and send the request to this endpoint, API can return us results something like this, an object with current temperature of 70 degrees Fahrenheit and humidity 45%. If we send the request to the second endpoint with the city name New York, and the second endpoint getCityForecast, that endpoint will return us the forecast for the tomorrow and the day after tomorrow. This is the general idea about the APIs, how the API works. And all modern applications are client-server applications built that way. When you do something in the web browser, web browsers send this information to the certain API endpoint, requesting this information from the web server. And server returns the information back to the browser, and then it displays on the web page. So what are the types of the API requests? So there are get, post, put, and delete. There are four most popular types of the API request. Get type of the request used when you want to request a specific data from the API. Post and put types of the request used when you want to update or create certain information in the API or in database. For example, you want to create a new customer in your database, and you send a post request to create this user. Or you want to update the email address for this user, then you would use put request to update email address for this user. And delete request is pretty much removes the specified resource. Typical API request consists of API URL. API URL is HTTP URL to the API, and usually it called API endpoint. Second component is headers. Usually it is content type, what type of the information you are requesting, and or authorization token. Authorization token is used for the secure APIs. To get access to the API and get the information from this API, you should be authorized, otherwise you will not be able to use it. Methods, as I mentioned, get, post, put, and delete. And body, it is a JSON object with requested data and used only for the post or put request. When you make a request, API provides you a response with a status code. And based on the status code, you can tell was it successful or not, or if something went wrong, what exactly happened. So if you have 200 types of status code, 200, 201, 204, and so on, it means that your request was successful, and API did what you requested it to do. The second type of status code is 300 types of the request, which is redirection to the different API URL. Usually when you request one API, but this API redirect you to other API to obtain this information. So you will see 300 status code for these types of operation. 400 status codes, like 400, 401, 404, and so on, it means a client error. This means that browser or any other framework or which is sending request to the API did something wrong. An API did not recognize this request. For example, if it is 400 error, it means that your request simply incorrect, an API did not recognize it. Or 401 error means that this request is not authorized and you need to provide authorization token. Or 404 means that URL simply does not exist and cannot be processed. And the last one is the 500 errors, it means a server error. 500, 501, 502 means that your request was correct, but something happened on the server side and server was not able to process the information and return you the expected result. Also 500 means that some unhandled exception happened on the server. Such type of the errors is difficult to debug and you actually need to log into that server, look into the logs, and debug the code to understand what's actually happened over there. And this is a typical example of the client-server architecture. Web browser is our client and API is our server. And when we click on the certain buttons in the web browser, it sends the request to the API, API provides the response, and this information displayed on the web browser. For example, let's say our web browser have username and password field and login button. Then we type username and password. And when we perform the click, browser sends the request with the object of username and password, john123 and password welcome1. And while API processing this request, usually on the browser you will see some icon that is saying that it is loading or waiting or something like that. So browser is waiting for the response from the API. When API process this request, it provides the response with the status code, usually is 200, and provides the response object. In this example, API return first name, last name, age of our user, 35, and access token that our browser can use in the future to interact with the API. And once this response is processed by the browser, we may see something like this. Welcome, John Smith, your age is 35. So this is the main concept, how the modern web application works and how do they interact with the APIs. And when we perform a functional UI end-to-end testing with a playwright, technically what we are doing. In the playwright, we perform certain operation in the web browser, clicking on the button. Browser send request to the API, API return this information, and then we validate this information through the playwright. And then repeating this operation again and again. And this can be called as a functional end-to-end test or functional integration test, because we are testing integration of the browser with the API. But what you can also do in the playwright, for example, we perform first operation, then browser send request to API server. We get a response process in the playwright, then we perform a second click on the button. And then playwright can intercept this call and we can provide the mock to our web browser back. Not letting this API call to go through and then make a validation inside of the playwright framework. So this technique called mocking of the API. This approach has certain advantages and disadvantages. The advantage of mocking of the API is, first of all, improvement of the speed of your test and stability of your test. Because you have 100% control over the data that will be returned back to the web browser. And you know that it will be returned for sure because you control this. And also it is faster because response is instant. You don't need to wait for the API response. The disadvantage for that is that you're breaking the actual integration test. And if your API server will have a change, your test will not catch this change. So this is a very tricky moment and you need carefully used API mocks. Using API mocks is useful when you have, for example, very slow endpoint or very unstable endpoint. Or let's say your application is dependent on the third party API, which is not stable and breaking your test time to time. In this case, it is considered a good approach to mock those APIs to improve the stability of the test and speed of execution. And the second approach you can do is, again, with sending the API request, and then for the second call, web browser is reaching the API server. But Playwright can intercept the response, make validation of this response, modify this response, and then send back a modified response back to web browser. And then make assertion in the Playwright. And one more thing that you can do with a Playwright is directly make API calls from the framework to the server without using a web browser. This is very useful, for example, for a headless authorization. When you don't need to use login and password screen every time to log in into application. Using the API call, you can directly call API server, get API token, authorize your browser, and then perform all the operations inside of the browser. This approach also improves the speed of execution of your test suite. All right, let's make a quick summary. API stands for Application Programming Interface. It's a kind of black box that you can interact with through the endpoints. Method types in the APIs the most popular are GET, POST, PUT, and DELETE. Typical API request has URL, headers, request type, and body. Status codes are 200 for success, 300 for redirect, 400 is a client error, and 400 is a server error. And in the Playwright, you can mock APIs, you can intercept the APIs and modify the response, or interact directly with the APIs to optimize the framework. All right, that's it guys, and see you in the next lesson.