What is API | Bondar Academy
Course: Mastering testRigor
Module: Working with APIs
Instructor: Artem Bondar
Lesson Summary
In this lesson, we explore how to use Test Trigger to interact with APIs, including direct interactions and mocking APIs for improved testing. This is particularly useful for testing edge cases and scenarios. What is an API? API stands for Application Programming Interface . It acts as a black box that you can interact with through API endpoints . For example, a weather API has two endpoints: GET endpoint for Dallas temperature POST endpoint for city temperature When you send a request to the GET endpoint, you receive a response in the form of a JSON object containing the current temperature. Types of API Requests GET : Retrieve specific data POST : Send data to create a resource PUT : Update an existing resource DELETE : Remove a resource HTTP Response Status Codes Understanding status codes is crucial: 200 : Success 300 : Redirection 400 : Client error (e.g., 404 for not found) 500 : Server error Using Test Trigger Test Trigger can: Mock APIs to simulate responses for testing Make direct API calls for efficient testing For example, to delete a user, you can create the user via an API call instead of through the application interface, speeding up the testing process. In summary, APIs are essential for application interaction, and Test Trigger provides powerful tools for testing API functionalities effectively.
Video Transcript
In this section, we will talk about how to use Test Trigger to interact with the APIs. So you can either interact with the APIs directly or you can mock the APIs using Test Trigger. And all that can make some improvements into your test, test edge cases, scenarios and other things. And if you didn't work with APIs before and don't have experience working with API, in this particular lesson, we will talk about in general what API is about, what is it and how to work and interact with the API. So let's get into it. So what is API? So API is an acronym for the Application Programming Interface. So API is essentially is a black box that you can interact with through the API endpoints. And for example, we have this weather API that we want to interact with. You don't know how this API works exactly inside and you don't need to know about it. All you need to know about is the API interface. And in our example, our API has two endpoints. First endpoint is the get endpoint for Dallas temperature. And the second is post endpoint for the city temperature. So this is the interface of our example API. And if you want to get, for example, temperature of the city of Dallas, and you send the request something like this, URL API.weatherAPI.com slash Dallas temperature. So assumption, this is the URL to our API. And you provide method get and send this request. API will provide you a response in form of the JSON object with the current temperature in Dallas. For example, it's in Celsius 25 and in Fahrenheit, it's 77 degrees. And that's all this endpoint can do. And every time you send the request to this endpoint, the API somehow receive this information for you and provide you current temperature in city of Dallas. And if you send this request, let's say in a couple of hours, the information will be updated and API will return you a new information. So this is what this endpoint can do. And we have a second endpoint, which is a post endpoint called city temperature. And if you send this kind of the request, for example, URL ends with a city temperature, the method is post. And also this endpoint can accept the payload in form of JSON body. And let's say this object will be city and New York. And if we send the city New York as a request to this endpoint, the API returns us information with the current city temperature in Celsius and Fahrenheit. For example, 15 degrees Celsius and 59 in Fahrenheit. And if you send, for example, San Francisco or Los Angeles or any other city as your payload to this API, API will return you the information about the temperature in the city that you have requested. So this is basically the main idea of how all APIs are working. This is a black box. This black box has interface in forms of the different endpoints. And you can send requests to these endpoints, obtaining the certain information in the form of the response. Usually the interaction with the APIs happen in the form of JSON objects. So you send JSON object with a request and receive the response in form of the JSON object. So let's move on. What are the main types of the API requests that you need to know? So get is just get the request for the specific data from the API. Post and put endpoint is when you need to send certain information to the API, create or update the resource. For example, if you would like to create a new customer for your application, most likely it will be a post request to create this information. But if you want to update the phone number for this customer, most likely it's going to be a put request for the API. And delete type of the request is simply removes the specified resource from the back end. There are also different type of HTTP response status codes. Every time you make a request to API endpoint, API provide you a response with a status code. And based on the status code, you can tell about how this operation was completed. Was it successful or not? And if not, what went wrong? So this is helpful to understand if this is working as expected or not. So 200 types of status code like 200, 201, 204 and so on means that overall the request was successful. So you sent your request. API processed your request and provide you the expected response. So everything working as normal. Some of those status codes, just a minor differences. For example, 200 is just OK that it was successful. 201 it is created and so on. The next group of status codes is 300, 301, 300, 302 and so on. It means that redirection happens. So you're sending requests to the API, but this API redirecting you to other API or to other resource to provide you this information. It's not happened that often, but still happens in the front end development. 400 status code such as 400, 401, 404 means a client error. It means that something happened on your end when you was requesting, when you was sending requests to the API. I think one of the most typical status codes that you should be familiar is 404. So sometimes you may open web application and you see, sorry, this page not found. And you see 404 status code. So 404 means that our application requested the page on the backend, but this page does not exist. This is, in other words, incorrect request for the page that exists. So the response from the server, from the backend API says, hey, this is not correct URL. It does not exist. So if you want me to provide you a response, please provide the correct request. So 404 is incorrect request for the resource that does not exist. 401, for example, is the incorrect authorization or authorization does not exist. So some of the APIs endpoint are secured. So only authorized user can request the data from this API. And if you send a request without a proper authorization, API will tell you, sorry, 401 unauthorized. I cannot let you to go through. So you need to fix the error on your side. And 400 is just a bad request. If you, for example, let's go back over here. So in this example, we were sending a request of city New York, right? But if you would try to send something like country New York or state New York to this endpoint, this API will return you a 400 error, such as bad request, because API does not understand what are you asking. It's not according to specification of the API. So you need to fix your request before moving forward. And the 500 status codes is a server side of the error, such as 500, 501, 502, and so on. It means that your request was correct. Server accepted your request as a valid correct request. But then something happened on the server side and server was not able to process your request for whatever reason. You don't know why. So this type of error is one of the most difficult one to figure out. So in most of the cases, when you have this type of error, you will need to support of your development team, ask them to look into the server logs and analyze what exactly happened on the server, why it was not able to process your request correctly. All right, so moving on. And this is the typical example of client-server application. Just want to show you the overall architecture, how most of the applications with the client-server architecture works. So this is our web browser on the left with username, password, field and login button. And somewhere we have a API server for this application. And when we enter, for example, username and password, john123 and password welcome, and we perform a click, our web browser sends the request to the API in form of the JSON object with the information that was provided inside of the browser, something like username john and password welcome. And while API processing this request, you will see on the browser something like loading or some kind of spinner or something like this. So it takes some time, half a second, second, it depends on the API, how long it will be able to process the request. And then API provide you a response also in the form of the JSON object. If the request was processed successfully, first name john, last name smith and age of 35. And when browser receive this response object back, it process this object. And then you can see on the page something, welcome john smith, your age is 35. So browser is processing the raw data returned from the API server in the form of the nice UI that you see on the page. And browser performs multiple requests and responses to different APIs during the usage of the application. So this is overall how the client server application works. And talking about functional end-to-end testing. So test trigger is our framework, right? And when we perform a test automation, so what actually happened? So test trigger interact with your web application, performing different operation, triggering certain command and so on. Web application send API request, API server processing this request, return the information to the web application. And then test trigger validates this on the framework side, right? Then next step, web application sending request, API providing response. And test trigger makes the validation of the information that is displayed on the web page. So this is the typical way how would we do end-to-end automation. But there are also scenarios how you can adjust the sequence. For example, test trigger interact with the web page, web page send request to API, API response, test trigger makes validation, everything is fine. Then for the next operation, test trigger interact with the web browser. But on the step when web application send request to the API, we intercept this API request using test trigger and providing our own response. So the request from the browser never reach the API server. We catch this and sending our desired response back. So the web application will think that this is a valid response from the API. But in reality, it's not. And then in test trigger, we make a validation based on the mock response that we provided by ourselves. So when mocking can be useful. For example, you want to test a difficult edge case scenarios of weird error messages on your page when setting up a test data for this kind of scenario is difficult, right? In this example, you can set up your own mock response and then run the test. And you will see this simulation on the web page with your own custom data that you have created. Another example of when using mocks is useful is when you have, let's say, third party API or slow API, which slows down the test execution for you a lot. And you know that that API will not be changed often. And to speed up the test execution, you can mock that particular endpoint, which is slow or not ready or not responsive or something like that with your own mock. And that way you can isolate your testing environment that way. And another example that in test trigger, you can also make the API request directly to the API server and process the response. For example, one of the scenarios like that, let's say you want to test the functionality of deleting the user from your application. But in order to delete the user, you need to create this user first, right? One of the way is just do it through the application. You go to the browser, you fill out the application form for the new user, you create it, and only then you start your test to delete the user. It's time consuming. The much faster way is just to make a simple and quick API request to the backend, create this user, get response from the server. So you will know, for example, user ID or something like this, and then run your normal end-to-end test through the web application, deleting this user. So how to use mocks, how to perform API calls? All we're going to talk about it in this particular section. So let's quickly summarize about the API. So API is an application program. Interface essentially is a black box with API endpoints that you can interact with. The most typical methods for APIs are get, post, put, and delete. Typical request consists of URL headers, request method, and request body. The typical status codes is 200 types of status codes is successful, 300 redirect, 400 it means that it was client error, and 500 is a server error. And TestRigger can mock APIs and interact with APIs directly. All right, that's it, guys, and see you in the next lesson.