What is API | Bondar Academy
Course: Playwright API Testing with TypeScript
Module: API Testing Basics
Instructor: Artem Bondar
Lesson Summary
API Overview API stands for Application Programming Interface , which facilitates communication between a client (like a browser) and a server. This interaction occurs via the HTTP protocol using URLs , also known as URIs (Uniform Resource Identifiers). API URL Components An API URL typically consists of: Protocol: Usually HTTPS Domain: e.g., example.com Path/Resource: e.g., /API/articles Query Parameters: Key-value pairs after a question mark, e.g., limit=10&offset=0 Types of API Requests There are four main types of API requests: POST: Create a new record GET: Read an existing record PUT: Update an existing record DELETE: Remove an existing record The acronym CRUD represents these operations: Create, Read, Update, Delete. HTTP Status Codes Common HTTP status codes include: 200 Level: Success (e.g., 201 , 204 ) 400 Level: Client error (e.g., malformed request) 500 Level: Server error (e.g., internal issues) Client-Server Interaction In a typical client-server architecture, a user submits information (like a username and password) via a web browser, which sends a POST request to the server. The server processes this request and responds with data, often in JSON format. API Automation For automation, instead of using UI testing frameworks like Playwright that interact with the browser, you can directly send API requests. This approach is faster and more stable, as it bypasses the UI rendering process. In this course, you will learn how to utilize Playwright for direct API interactions to enhance testing speed and reliability.
Video Transcript
All right guys, before we begin automating APIs, first of all, let's talk about what is API. So in case you're just starting your journey in API automation, I want to make sure that we are speaking the same language and talking about the same thing. So we talk about what is API in general, how to interact with API, the status codes, type of the methods, and so on. So let's get into it. API stands for Application Programming Interface. And to be honest with you, this name is kind of weird because this is not really about the programming. It's more about communication with the server. So the correct name would be something like Application Communication Interface because this is how our client, which is a browser or other system, interacts with the server, interchanging different information, requesting the information and getting the response from the server. Interactions with API happening through the HTTP protocol using just a regular URLs. And the URL to the API called URI, which stands for Uniform Resource Identifier, or also it's called URL. So both is correct, Uniform Resource Locator. So either URI or URL term used for the API's URLs. And here's the example of two URLs. For example, example.com slash API articles and example.com API tags. So those are two addresses or resources on the server that you can request from the server by the client. And when you send the request to the articles resource or the articles endpoint, for example, then the server receives this information based on the path inside of this URL. And server knows, okay, I need to request information, let's say from the articles table. Or if you need to request a tags endpoint, for example, at the same API, then server will know that based on the path, I will need to look to the tags table and return some information from the tags table. Now let's talk about the API URL components. So what the API URL consists of. So this is the typical example of the API URL. And we will talk at this example, two terminologies types. So one is just the general what the URL consists of. So it starts with protocol, which is normally HTTPS. Then example.com is the domain for the API. Then it's appended by the path or resource on the API that we should reach or want to reach to get information from. And also it can be appended with the query parameters. Query parameters are added after the question mark and represents the key and value pairs separated by this ampersand. For example, limit equals to 10 and offset equals to zero. So limit equals to 10 means for the API that API should return just 10 articles, no more than that. We're requesting 10 articles and server will return us 10 articles because we requested this in the parameters. If we talk in the context of the API automation, we can use the following language. For example, API base URL may consist of the entire protocol domain, a part of the path that would represent a constant inside of our framework. For example, you can take this base URL, save into the constant and use as your environment variable somewhere in the settings. And then you have a path or resource or it's also called endpoint. In this example, this is the articles which is appending to the base URL. And the resource or this endpoint becomes your variable which you use inside of the test. And depending on the test, you're just changing the path, appending it to the base URL. And the query parameters remain the same. So you either have query parameters or you don't have query parameters. Query parameters typically related to the GET requests. And now let's talk about the types of the requests. So there are four main types of the API requests. So POST type of the request is when you want to create a new record on the server. GET type of the request, when you want to read the existing record. PUT type of the request is you want to update the existing record and DELETE is just delete the existing record. And you probably heard about the acronym CRUD. So CRUD represents the Create, Read, Update and Delete. So when you hear something saying like CRUD API, it means that this API or operation when you create, read, update or delete all those typical four operations. Okay, how typical API POST request would look like. So you make a POST request from the client to the server. And the typical request consists of URL, which consists the domain and path to the resource or endpoint, which in this example is tags. Also, the request has typically headers. In this example, it is either type of the data that we are requesting. For example, application JSON or the compatibility type. And it's quite typical to have an authorization token. If this is a secure API, you also need to provide authorization credentials or token inside of the header to make a call secured. And also there is a request body that's typically provided in the form of the JSON object. And in this example, we sending requests to our server to create a new tag with the text, Hello World. When we create the request, server have to respond us with some information. So server provide the response and one server has. So first of all, server returns a status code. By knowing the status code, you can tell what's the operation was successful or not. Or if not, then what possibly could go wrong. And also it's possible that API will provide you a body. This is the optional. And if the body is returned, it's also typically a JSON object with some useful information. For example, in this example, we have created tag, Hello World. So API just responded to us that the tag that we asked it to create, it was created. Now let's talk about the typical HTTP status codes. So if server responded with a 200 level status code, such as 201, 204, and so on, it means that success. Operation was successful and API did what we asked it to do. The 400 level status code, it means there's something wrong with the request or something wrong with the client side. It means that we requested API to do something that API is not designed to do or API did not understand what we requested. In this type of situation, we need to review our request and check, did we do everything correctly? Did we constructed our request with all required parameters that API expecting from us? And the 500 level status code is something wrong at the server side. So we did everything correctly, we send the request, but then something happened on the server side, we don't know what exactly, and API just was not able to provide us response that we expected from it. Sometimes API may return you some error message server related error message that can help you to debug this problem then on the server side. And let me show you the example of the typical client server application architecture. So on the left, we have a web browser with just username, password, and login button. And on the right is our server. Then user is just entering username and password, John123, welcome. And when the user clicks the login button, browser immediately send the post request with entered information in the browser. For example, username and password. Server is processing this information and while server processing this information, you will see on the browser, typically like loading or something like this. So web browser waiting for the response from the server. So server got this information, processed it. If the request was correct, server provide the response with the details about the user. In our example, it first name John, last name is Smith, and the age of 35. And this information also provided in the form of JSON object in the JSON response. Then this information is processed by the browser and we may see something like this. Welcome John Smith, your age is 35. So that's how typically client server application works and how browser interacts with a server exchanging the different types of the data. And now let's talk about automation. So when you write your test for the application, for example, using Playwright UI automation, you would have a framework, you would have your web application under test and your web application talk to the server. So the entire stack would look like this. Playwright interacting with your web application, clicking on some buttons on the screen, then application send request to the server, server response, this information updated on the UI on the webpage, and then Playwright make validations of what was changed on the screen. When you run the next test, applications make those requests to the server, information coming back, and so on. This is how the UI automation would work. This is high level architecture. And the problem with this approach that is very slow. So UI automation is naturally quite slow and also flaky. And what you can do instead to speed up your automated testing is just to replace the browser entirely and interact with the server directly using Playwright framework, triggering the API requests and processing the response. That way, the test will be super fast because you eliminate completely the slowness of the browser and also much, much stable because you will not have a dependency on the rendering of the UI, UI components, and so on. And this is what we're gonna do in this course. I will show you how you can leverage Playwright to interact with the APIs directly, speeding up your test execution by a lot and making your test significantly more faster. All right, so see you in the next lesson.