API testing can be one of the most challenging parts of the software and QA testing because APIs can be complicated. They are often based on protocols and standards that we often do not encounter in other kinds of testing.
 

What is API?

Application Programming Interface (API) Allows two applications to interact with each other without any user intervention. API is a collection of software functions and procedures. In simple terms, API means a software code that can be accessed or executed. API is defined as a code that helps two different software.

 

What is API testing?

API testing is designed to validate the business logic as well as the performance, security, and other aspects of the application. API testing does not focus on the individual components of an application, like unit testing, or the look and feel of the application, like user interface (UI) testing, but on what the application does.

API testing allows developer operations, quality assurance, development, and other teams to begin testing an application’s core functionality before the user interface is ready. This enables them to identify any errors or weaknesses early on in the development process. If identified later in the process, these errors and weaknesses in the build can be costly to fix, requiring large amounts of code to be rewritten and significantly delaying the product’s release.
 

Types of API testing:

Below are examples of types of API testing.

• Functional testing
  These API tests are designed to check that an API returns the right response for a given request.
   
• Runtime and error detection testing
  These API tests are designed to check the actual running of the API and typically focus on monitoring, execution errors, resource leaks, or error detection. Security testing. These tests lead to knowing how an API responds to and resists cyberattacks.
   
• Load testing.
  This type of API test is used to know how an API handles a large volume of requests over a short period.
   
• Penetration testing.
  Penetration tests involve users with limited API knowledge trying to attack the API, which enables testers to assess the threat vector from an outside perspective.
   
• Validation testing.
  Validation tests are run late in the testing stage to verify the behavior and efficiency of the API.

Different tools available for API Testing:

Different tools available for API testing are:

1. Postman (Best API Testing Tool)
2. RESTAssured (Best Tool for Automation Testing)
3.  Swagger (Best Tool for Designing and Document REST APIs)
4. Ready API
5. Katalon Platform

Postman

Key Highlights:
Postman provides a list of assertions, so users have the freedom to manipulate the received data in different ways, such as creating local variables or even creating loops to repeatedly run a test.

Postman allows the creation of collections of integration tests to ensure that API is working as expected.

With the help of Postman, we can reuse the code(assertions) written for one environment for multiple other environments.

Why use Postman:
 

• Collaboration:
  Collections and environments can be imported or exported, making it easy to share files. A direct link can also be used to share collections.
   
• Use of Collections: 
  Postman lets users create collections for their Postman API calls. Each collection can create subfolders and multiple requests. This helps in organizing your test suites.
   
• Automation Testing:
  Through the use of the Collection Runner or Newman, tests can be run in multiple iterations saving time for repetitive tests.
   
• Debugging:
  The Postman console helps to check what data has been retrieved, making it easy to debug tests.
   
• Creation of Tests:
  Test checkpoints, such as verifying for successful HTTP response status, can be added to each Postman API call which helps ensure test coverage.

How to use Postman:

1. New – This is where you will create a new request, collection, or environment.
2. Import – This is used to import a collection or environment. There are options such as importing from a file, folder, link, or pasting the raw text.
3. Runner – Automation tests can be executed through the Collection Runner. This will be discussed further in the next lesson.
4. Open New – Open a new tab, Postman Window or Runner Window, by clicking this button.
5. My Workspace – You can create a new workspace individually or as a team.
6. Invite – Collaborate on a workspace by inviting team members.
7. History – Past requests that you have sent will be displayed in History. This makes it easy to track actions that you have done.
8. Collections – Organize your test suite by creating collections. Each collection may have subfolders and multiple requests. A request or folder can also be duplicated as well.
9. Request tab – This displays the title of the request you are working on. By default, “Untitled Request” would be displayed for requests without titles.
10. HTTP Request – Clicking this would display a dropdown list of different requests such as GET, POST, COPY, DELETE, etc. In Postman API testing, the most commonly used requests are GET and POST.
11. Request URL – Also known as an endpoint, this is where you will identify the link to where the API will communicate with.
12. Save – If there are changes to a request, clicking save is a must so that new changes will not be lost or overwritten.
13. Params – This is where you will write parameters needed for a request, such as key values.
14. Authorization – To access APIs, proper authorization is needed. It may be in the form of a username and password, bearer token, etc.
15. Headers – You can set headers such as content type JSON depending on the organization's needs.
16. Body – This is where one can customize details in a request commonly used in POST requests.
17. Pre-request Script – These are scripts that will be executed before the request. Usually, pre-request scripts for the setting environment are used to ensure that tests will be run in the correct environment.
18. Tests – These are scripts executed during the request. It is important to have tests as it sets up checkpoints to verify if the response status is ok if retrieved data is as expected and other tests.

What is a “GET” Request:

GET requests will not affect any data on the server. When you make the GET request on the server, then the server responds to the request. This means there is no creation, update, addition, or deletion of data on the server when you are making a GET request.

GET requests to contain all information inside the URL, and because of that, some people do not prefer to use GET requests while they are sending confidential data such as passwords. For example, if you search anything on Google, you are using a GET request because there is no sensitive information, and you are just requesting the page. You can try to search for something on Google; you will get the same search string in the URL.

What is a “Post” Request:

We use this method when additional information needs to be sent to the server inside the body of the request. In general, when we submit a POST request, we expect to have some changes on the server, such as updating, removing or inserting.

One of the best examples of using POST requests is the login page of Instagram or the login page of other sites; you send your personal information, such as the password, to the server. The server creates a new account with the same information and that account, and the information is added permanently to the Instagram server.

• 201 with a location header pointing to the new resource.
• 400 if the new item is not created.

What is a “Put” Request: A PUT request is used to pass data to the server for the creation or modification of a resource.

• 204 for OK/SUCCESS (but no content).
• 200 for OK with Content Body (Updated response).
• 400 if the data sent was invalid. 

What is a “Delete” Request:
The DELETE method sends a request to the server to delete the request mentioned in the endpoint.
 

• 200 (OK)
• 204 (if there is no content for the record that we want to delete)
• 202 (Accepted, deletion is not a single operation).

Stander status code for Response:

• 201: For a successful request and data was created.
• 204: For empty response.
• 200: This code is used for a successful request.
• 400: This is used for Bad Request. If you enter something wrong or you miss some required parameters, then the request will not be understood by the server, and you will get a 400-status code
• 401: This is used for Unauthorized Access. If the request authentication fails or the user does not have permission for the requested operations, then you will get a 401 status code.
• 503: And this code is used for Service Unavailable.
• 403: This is for Forbidden or Access Denied.
• 404: This will come if the Data is Not Found.
• 405: This will come if the method is not allowed or if the requested method is not supported.
• 500: This code is used for Internal Server Errors.

What are Assertions?

Assertions are used to verify if the actual and expected values have matched after the execution of a test. If they are not matching, the test shall fail, and we shall get the reason for failure from the output of the test.

An assertion returns a Boolean value of either true or false. In Postman, we can take the help of the JavaScript Chai Assertion Library to add assertions to our tests. It is available in the Postman application automatically.
 

Conclusion Application Programming Interface lets two applications interact with each other without user intervention. API testing includes the process of validating the business logic with regard to the performance and security of an application. Functional testing, runtime and error detection testing, load testing, penetration, and validation testing. Some of the tools for this API testing are Postman, RESTAssured, Swagger, ReadyAPI, Katalon, etc. Each of these tools comes with its own limitations and benefits. If you are also looking for API solutions for your enterprise and API testing on your existing project, you can get in touch with us for API testing and other Digital Enterprise Solutions.