My Certificate Find a Certificate About Certification QA Terminology Basics of Software Testing Basics of Test Automation QA Processes Overview Basics of testRigor BDD & SDD Web Testing Overview Mobile Testing Overview Native Desktop App Testing Overview API Testing Overview Click / Drag / Hover Entering Data Variables Validations Scrolls and Swipes Dealing with Dates and Times Dealing with Emails Working with Tables Conditional Sequences Cycles & Loops Reusable Rules SMS and Phone Calls Managing Multiple Environments Settings Integrations AI and Prompt Engineering Final Exam

Generative AI-Based Testing Certification

API Testing Overview

API Testing Overview

API (Application Programming Interface)

An API, or Application Programming Interface, is a set of rules and protocols that allows one software application to interact with another. It defines the methods and data formats that software components should use to request and exchange information. APIs are used in a multitude of contexts, from web development, where they can be utilized to fetch data from a server, to operating systems where applications use APIs to request services from the OS, to hardware where drivers use APIs to communicate with devices. In modern software development, APIs often serve as the bridge between different software systems, allowing them to work together, such as integrating third-party services or enabling mobile apps to fetch data from servers.

Still confused about what the API is? Think of an API as a waiter in a restaurant. You, the customer, sit at the table with a menu of choices to order from. The kitchen, where the food is made, represents a system or service you want information from. You need a way to communicate your order to the kitchen and then have your food brought back to you. Instead of going to the kitchen yourself, you tell the waiter (API) what you want. The waiter then takes your request to the kitchen, and once the food is ready, the waiter brings it back to you.

Similarly, in the digital world, when one software wants specific information from another software (like fetching weather data or posting a picture), it sends a request via an API. The API is the intermediary that understands the request, communicates it to the other system, and then brings back the desired data or result.

On testRigor, although there are many other applications, API functionality within test cases is primarily to aid in the completion of end-to-end flows on a UI.

Most Common Request Types: GET, POST, PUT, DELETE

  1. GET: This is one of the most commonly used HTTP methods. It is used to retrieve data from a server. When you visit a website or click on a link, you’re often making a GET request. It is read-only and has no side-effects, meaning it doesn’t change any data on the server. Example
  2. POST: This method is used to send data to a server to create a new resource. It’s often used when submitting form data or uploading a file. Unlike GET, POST requests can change the data on a server. Example
  3. PUT: This is used to update an existing resource or create it if it doesn’t exist. The request typically includes the data or changes you want to apply to the resource. Example
  4. DELETE: As the name suggests, this method is used to delete a specified resource. Once executed, the resource is removed. Example

Among these, GET and POST are used most frequently. GET is commonly utilized for fetching data while POST is used for sending data. PUT and DELETE are essential for applications that need full CRUD (Create, Read, Update, Delete) capabilities but might be used less frequently than the former two depending on the application’s nature.

See other request types and examples here.

API Status Codes

API status codes are three-digit numbers that provide a quick indication regarding the result of an HTTP request made to a server. They tell the client (usually a browser or an application) if the request was successful, if there was an error, or if the client needs to do something else to fulfill the request. They can be seen as the server’s way of saying “Got it!”, “Oops! Something went wrong.”, or “I need more from you.”

Most Common API Status Codes:
  1. 1xx (Informational): These are provisional responses indicating that everything is okay so far and the client should continue with the request or ignore it if it’s already done.
  2. 2xx (Successful): The request was successfully received, understood, and accepted.
    • 200 OK: Standard response for successful requests.
    • 201 Created: The request has been fulfilled, and a new resource has been created.
  3. 3xx (Redirection): The client must take additional action to complete the request.
    • 301 Moved Permanently: The URL of the requested resource has been changed permanently.
    • 302 Found: The resource has been moved temporarily to a different URL.
  4. 4xx (Client Errors): The request contains bad syntax or cannot be fulfilled by the server.
    • 400 Bad Request: The server couldn’t understand the request due to invalid syntax.
    • 401 Unauthorized: The request lacks proper authentication.
    • 403 Forbidden: The server understands the request, but it refuses to fulfill it.
    • 404 Not Found: The server can’t find the requested resource.
  5. 5xx (Server Errors): The server failed to fulfill a valid request.
    • 500 Internal Server Error: A generic error message when an unknown error occurs on the server.
    • 502 Bad Gateway: The server received an invalid response from an upstream server.
    • 503 Service Unavailable: The server is not ready to handle the request, maybe because it’s overloaded or under maintenance.
testRigor supports calling APIs, retrieving values, and saving results as stored values. Below is the command format:
call api <TYPE> "<API_URL>" with headers "a:a" and "b:b" and body "body" and get "JsonPath" and save it as "variableName"
Here is an example:
call api post "http://dummy.restapiexample.com/api/v1/create" with headers "Content-Type:application/json" and "Accept:application/json" and body "{\"name\":\"James\",\"salary\":\"123\",\"age\":\"32\"}" and get "$.data.name" and save it as "createdName"  and then check that http code is 200

Mocking in API testing means replacing a part of the system with a dummy version to isolate and test other system parts. Using testRigor, you can mock response data, including headers, the body, and/or HTTP status codes, for API calls made within your application. For clarity, testRigor is not primarily designed for API testing; rather, API testing is a supplemental feature. Overall, if you’re unfamiliar with APIs – it’s advisable to consult your software developer for assistance.

Mocking API calls

testRigor supports mocking response data (headers, body and/or http status code) for API calls made inside your application.
mock api call <TYPE> "<API_URL>" returning body "<MOCK_BODY>"
For example:
mock api call get "https://dummy.restapiexample.com/api/v1/employees" with headers "a:a" returning body "This is a mock response" with http status code 200
In the example above any GET calls to the endpoint “https://dummy.restapiexample.com/api/v1/employees” with the headers “a:a” will respond with the testRigor mock, with status 200.
Some useful cases are:
  • You might want to use mocking APIs if you are using third-party API calls. Those calls can be charged and expensive, so you can mock the responses instead of calling the real service.
  • You can test your application individually if servers are unstable or down.
  • You can test specific scenarios, for example, if you want to test a scenario where the server returns error.
  • You can intercept API calls made by interacting with a system and validate that they were made and the response returned.

Test your knowledge

GET
POST
PUT
DELETE
Making fun of the API for its errors
Intercepting an API call made by interacting with the UI like clicking on a button
Creating a model of the API for visualization
Testing the API without any actual requests
© 2023 testRigor. All rights reserved.