An API (Application programming interface) is a set of tools that are used to build software and also make them communicate with each other. The way this is done is by using REST for formatting the information payload requested by the client with a standard text format like JSON, XML or raw text, then the data is sent to the server with HTTP methods like GET, POST, PUT and DELETE to name a few, the server then interprets the data, performs the action requested and sends the data back to the client.
As technical as that definition can be it took me some time to get it all together, there are way too many good and extended definitions of what an API is, but it all can be summed up to an analogy that you have probably seen in a youtube video or another blog.
“You (the client) are in a restaurant and you wish to order food to the kitchen(the system) here is when the waiter(API) comes in to take and deliver your order to the kitchen, then the kitchen prepares your order and the waiter comes back with the food order requested.”
A real-world example of this is whenever we want to sign in to a web application like Gmail.
We fill the required fields like email address and password, then the API takes that information to the system, then the system validates if the email and password are stored in the database and depending on the outcome of the validation the API returns with the webpage bypass access to the user, a message saying that the action could not be completed because the user is not registered, the username is not valid or that the password is incorrect. APIs are under the hood operations that are not visible to the user while it is in the GUI (Graphical User Interface).
Getting familiar with APIs and how they work gives a wide number of advantages from building and optimizing your software to knowing how to test key features that are the main interest of the business. This part is important because APIs are seen as part of the business layer of the software architecture.
As software testers, we can expand our test scope in a significantly more efficient way since there is no GUI interaction, the test scenarios can be executed and the results can be collected a lot faster. For example.
Test Scenario: Validate input search
Test Cases:
- Check the input search with an empty field.
- Check the input search with special characters.
- Check the character limit in the input search.
- Check the input search with SQL expression.
- Check the input search with HTML tags.
As you can see this scenario is not different from what we could do in a GUI but with the twist that we don’t have to open a web browser to access the URL, look for the specific input search that needs to be tested and then applying the test cases. All this can be done by simply sending a GET request with the correct URL and the desired parameters or variables.
To perform the tests there are several tools that can be used from an OS terminal to dedicated software like Postman or SoapUI. I’ll cover these tools in part 2 where I’ll go through its features, advantages, and disadvantages.
Top comments (2)
Good article, I can't wait for part 2. I like your waiter analogy! I am familiar with most of the running parts of a restaurant over the decades, but for some reason the waiter analogy never occurred to me! I've been trying to explain this area to a couple of people lately, and this will make things click right away. Thanks man, I appreciate it. Cheers!
Thanks a lot! really glad that this article can help you out. As many more people in the community, took me a while to get the hang of it and I decided that it would be great to simplify it in a technical and general definition for a better understanding of the concept.