Getting started with API Testing

Understanding the API jargon:-

It's critical to understand the terminology as we go into the weeds of API testing. These are terms that we frequently hear in the API industry, and they help us think about and test APIs. API Nouns are the URIs that you'd use to make an API Request.

GET:-

Use Receive queries to get resource representations/information only, not to modify it. Because GET requests do not change the state of the resource, they are deemed safe. Furthermore, GET APIs should be idempotent, which implies that repeating identical requests should always return the same result until another API (POST or PUT) alters the status of the server resource.

POST:-

Use the POST APIs to build new subordinate resources. A file, for example, is subordinate to the directory in which it resides, and a record to a database table. Strictly speaking, in terms of REST, the POST method is used to add new resources to the resource collection. The response from this method cannot be cached unless the required Cache Control or Expires header fields are included. Remember that POST is not safe or idempotent, so executing two identical POST requests will result in two different resources with the same data (except for resource identifiers).

PUT:-

In most cases, the PUT API is used to update an existing resource (if the resource does not exist, the API may decide to create a new resource). If the PUT API creates a new resource or modifies an existing resource, the origin server MUST notify the user agent using the HTTP response code 201 (Created), To signify successful completion of the request, either the 200 (OK) or 204 (No Content) response codes SHOULD be provided.

PATCH:-

PATCH requests are HTTP requests that perform a partial change to a resource. To be clear, the PATCH method is the ideal solution for partially altering an existing resource, but PUT should only be used if you're entirely replacing a resource.

DELETE:-

Idempotent is the DELETE command. When you DELETE a resource from the collection, it is no longer available. Repeating the DELETE API call on that resource will have no impact; however, doing it a second time will result in a 404 (NOT FOUND) since it has already been deleted. It's conceivable that this makes the DELETE method non-idempotent as a result of this.

Types of APIs:-

REST: When you build a REST API, you're following principles laid out in Roy Fielding's Ph.D. thesis. This is a set of principles for developing APIs that are both consistent and simple to use. RESTful APIs are the most common today, and if you're not sure what sort of API you're dealing with, RESTful is a good guess. Unlike other web services, REST is a set of architectural principles rather than a protocol.

SOAP: (Simple Object Access Protocol): This is a data-transfer protocol that leverages the XML format. Its primary role is to specify the structure of messages and communication mechanisms. It also publishes a description of its interface using WSDL, or Web Services Definition Language, as a machine-readable document.

API Testing Methodology:-

A tester should focus on utilising software to perform API calls in order to get an output before observing and reporting the system's response. This test ensures that the API responds or outputs correctly in a range of scenarios.

This result can be one of the following three:

1. The result is either a pass or a fail.
2. Information or data.
3. A call to a different API.

When testing the API directly, specifying pass/fail situations is a little more challenging. On the other side, comparing the API data in the response or the behaviour after an API request in another API might help you set up specific validation situations.

Because API testing guarantees that our digital lives become more fluid and efficient, it is one of the most difficult elements of the software testing and QA testing process. While developers are more likely to test simply the features they are working on, testers are in charge of assessing both individual functions as well as a series and chain of capabilities to evaluate how they interact from start to finish.

API Test Automation:-

A number of tools may be used to test the APIs. When a tester is given the task of testing an API, they must first get the documentation for the API.

The request format, response, error codes, resource, necessary arguments, optional parameters, headers, and other data are often included in API documentation.

APIs are often quicker and lend themselves nicely to automated testing, thus using them for test automation is typically favourable. We frequently think of test automation as being an extension of exploratory testing, and exploratory testing does indeed reveal what we need to automate.

Exploration and automation, on the other hand, are typically aiming to achieve different goals, so we must consider them separately.

API Test Automation Techniques:-

Data-Driven: Analysing each endpoint or combination of endpoints to see what data is available in the system and what we need to iterate or repeat over and over.

Workflow-driven: Simulating a user's workflow by making a series of API calls in a certain order. In this case, we're trying it out more like a consumer would. We're employing a procedure that a client may employ.

Tools used for API testing:-

Postman, TestProject, Rest-Assured, JMeter, and other technologies can assist you in creating API tests and automated tests.