Understanding API Testing

New API testers may find themselves feeling lost when they first start API testing. While the process might seem daunting, there’s no need to worry. The chances are that new API tests have all the information they need already!

API testing is a software testing practice that assesses an API’s functionality, reliability, performance, and security. As part of integration testing, API testing effectively validates the logic of the build architecture within a short amount of time.

Basic Validations to Test in an API

• Request headers
• Request body
• Response codes
• Response JSON
• Performance (Response Time)

Categories for Test Scenarios

• Positive tests
• Extended Positive Tests (With Optional Parameters)
• Negative tests with valid entries
• Negative tests with invalid entries
• Destructive tests
• Security tests, permits, and authorization

Some examples of websites that provide APIs are:

• Twitter: access to user data
• Google: to consume a Google Maps API

API or Web Service?

That question can confuse many people. So let’s explain the differences:

An API (Application Programming Interface) is a software interface that allows two applications to interact with each other, and it is not limited to a data transfer format.

A Web Service is a collection of open protocols and standards used to exchange data between systems or applications. A web service will generally use the HTTP protocol to communicate. Other protocols include SOAP, REST, and XML-RPC. Therefore, it can be said that a web service is an API that communicates via HTTP.

Differences Between APIs and Web Services

• Web services support XML, while API supports XML and JSON.
• All Web services are APIs, but all APIs are not web services.
• Web service supports only HTTP protocol, whereas API supports HTTP/HTTPS protocol.

Types of Web Services

Web services should be implemented in different ways. The two types of web services are SOAP and RESTful web services.

SOAP (Simple Object Access Protocol)

It is a protocol that was designed before REST came into the picture. The main idea behind creating SOAP was to ensure that programs built on different platforms and programming languages could securely exchange data.

REST (Representational State Transfer)

REST was explicitly designed to work with media components, files, or even objects on a particular hardware device. Therefore, any web service which is defined on the principles of REST can be called a RESTful web service. REST uses the normal HTTP verbs of GET, POST, PUT, and DELETE to work with the required components.

The Anatomy of REST

It’s important to know that a request is made up of four parts:

1. The Method

REST implements multiple ‘methods’ for different types of requests. The following are the most popular:

• GET: Get a resource from the server.
• POST: Create a resource for the server.
• PATCH / PUT: Update existing resources on the server.
• DELETE: Delete existing resources from the server.

2. The Headers

Additional details are provided for communication between the client and server. The common headers are:

Request:

• host: the IP of the client (where the request originated).
• accept-language: language understandable by the client.
• user-agent: data about the client, operating system, and vendor.

Response:

• status: the status of a request or HTTP code.
• content-type: type of resource sent by the server.
• set-cookie: sets cookies by server

3. The Data or Body

It contains the info to send to the server.

4. The endpoint (route) is the URL of the request.

It follows this structure:

In addition to this, the APIs can receive some API parameters: 

• Path: required to access the resource (/users, /tests, etc.)
• Query parameters: /tests?status=passed

Request Code Status Response

HTTP response status codes indicate whether a specific HTTP request has been successfully completed. The first digit of the status-code defines the class of response, while the last two digits do not have any classifying or categorization role. Responses are grouped into five classes:

Conclusion

To summarize, a web service is an API since it exposes an interface for two computers/systems to communicate, but only if it is in XML. On the other hand, an API is not always a web service since it does not limit its communication to the XML format.

Considering all these concepts, we can say that we are ready to start creating real test cases for the APIs without failing in the attempt. So, in the following blogs, we will start using Curl and Postman to create some API Testing.

Author: Ariana Franco