API Testing Interview Questions - Part 1

 1. API

  API is an application programming interface that acts as an intermediate between two applications. API is a collection of functions and procedures.

2. API Methods:

  GET - GET requests are used to retrieve the information from the given URL.

  POST - To send the new data to an api.

  PUT - This method is used to update the existing data.

  DELETE - This is used to remove or delete the existing.

  PATCH - Partially updated resource.

3. What is the difference between the 201 and 204 Status codes?

• 201 - The request was successful, and a new resource was created.
• 204 - The request was successful, but there is no response body. When an update or delete operation is successful.

4. What is the difference between 401 and 403 Status Code?

• 401 - Unauthorized. without logging in or with invalid credentials.
• 403 - Forbidden. When a logged-in user tries to access a restricted area without the required permissions.

5. What is the difference between Query Parameters and Path Parameters?

• Both Query Parameters and Path Parameters are used to send data in API requests.

6. How does an API Work?

• Client request -> Server Processing -> Response - Client Handling

7. Main types of API?

• Public API
• Private API
• Partner API
• Comboste API

8. What must be checked when performing API testing?

• Accuracy of data
• HTTP status codes
• Data type, validations, order, and completeness
• Authorization checks
• Implementation of response timeout
• Error codes in case the API returns, and

9. How do you handle dynamic data in API testing?

• Data Parameterization: Using data-driven tests where input values are generated dynamically from a data source (e.g., database, files).

10. What are the major challenges faced in API testing?

• Output verification and validation.

11. Difference b/w RESTful API and SOAP API?

• RESTful API and SOAP API lie in their architectural styles and message formats.

12. API Endpoint - Refers to a specific URL or URI

13. Purpose of authentication:

• Verify the requester's identity before granting access to protected resources.

14. Authentication methods used in API Testing:

• Token-based authentication - A token to the client after successful authentication.
• Basic authentication - sending the username and password 

Global vs Environment vs Collection Variables in Postman – Key Differences Explained

Global Variables:

• Stored globally across all requests and collections.
• It can be accessed from any request or collection.
• Use cases: API keys, common headers, or base URLs

Environment Variables:

• Stored within a specific environment (e.g., dev, staging, prod).
• It can be accessed only from requests within the same environment.
• Use cases: Environment-specific settings, such as URLs, credentials, or timeouts.

Collection Variables:

• Stored within a specific collection.
• It can be accessed only from requests within the same collection.
• Use cases: Collection-specific settings, such as API endpoints, headers, or query parameters.

Interesting aspects of API testing

1. Security Testing: Identifying vulnerabilities and ensuring secure data transmission.
2. Performance Testing: Measuring API response times, throughput, and scalability.
3. Functional Testing: Verifying API endpoints, request/response formats, and business logic.
4. Usability Testing: Ensuring API documentation, error handling, and user experience are intuitive.
5. Penetration Testing: Simulating attacks to identify vulnerabilities and weaknesses.
6. Fuzz Testing: Sending invalid or malformed requests to test API robustness.
7. Load Testing: Simulating high traffic to ensure API performance under stress.
8. API Gateway Testing: Testing API gateways, like AWS API Gateway or Azure API Management.
9. Microservices Testing: Testing APIs in microservices architecture, ensuring seamless communication.
10. CI/CD Integration: Automating API testing in continuous integration and continuous deployment pipelines.

Reducing API Latency and Improving Response Times

1. Caching: Implement caching mechanisms, like Redis or Memcached, to store frequently accessed data.
2. Content Delivery Networks (CDNs): Use CDNs to distribute content across multiple servers, reducing the distance between users and data.
3. Optimize database queries: Use efficient database queries, indexing, and connection pooling to reduce database latency.
4. Code optimization: Optimize code, use efficient algorithms, and minimize computational complexity.
5. Parallel processing: Use parallel processing techniques, like multi-threading or async processing, to handle requests concurrently.
6. HTTP/2 and HTTP/3: Upgrade to newer HTTP protocols, which provide improved performance and multiplexing capabilities.
7. Serverless architecture: Consider serverless architectures, like AWS Lambda, to reduce server overhead and latency.
8. Load balancing: Use load balancers to distribute incoming traffic across multiple servers, reducing the load on individual servers.
9. Monitoring and analytics: Use tools like New Relic, Datadog, or Prometheus to monitor performance and identify bottlenecks.
10. Continuous optimization: Regularly review and optimize API performance, as changes in usage patterns or data can impact response times.

Common API Test Cases: Essential Checklist for Effective API Testing

 

API Status Codes with Real Time Examples

HTTP 500 Series Status Codes:

• HTTP status codes in the 500 series are server error responses.

1. 500 Internal Server Error

• It occurs when a server meets with an unexpected condition. It indicates that the server encountered an unexpected condition that prevented it from fulfilling the request. The exact cause of the error is not specified in the response, making it a generic error message.

Example:

• Imagine you are using an online banking application. You have logged in successfully and want to transfer money to a friend. You fill out the form with the necessary details and hit the 'Transfer' button. Instead of processing the transaction, the application shows a '500 Internal Server Error message.

Cause:

• This could be due to several reasons, such as a bug in the application code, an issue with the server configuration, or a problem with the database connection. For instance, if the code that processes the transaction has a programming error or the database server is down, the web server might not be able to complete your request, resulting in this error.

2. 501 Not Implemented

• It indicates that a server doesn’t recognize the requested method or is unable to process that type of request.

Example:

• Suppose you are using a RESTful API to manage your online store inventory. You send a request using a new HTTP method called 'PATCH' to update part of the inventory data.

Cause:

• If the server you are communicating with has not been programmed to handle the PATCH method, it will return a 501 Not Implemented error. The server might only support GET, POST, PUT, and DELETE methods, and hence does not understand or implement the PATCH method.

  
3. 502 Bad Gateway

• It happens when a server receives an invalid response from the upstream server.

Example:

• You are trying to access a news website. The website's server needs to fetch the latest news articles from another server (an upstream server).

Cause:

• If the upstream server is down or returns a corrupted response, the main server cannot retrieve the necessary data and responds with a 502 Bad Gateway error. This typically happens in complex server architectures where one server relies on another to get the required information.

  
4. 503 Service Unavailable

• It indicates that the server is temporarily down for maintenance or overloaded.

Example:

• A popular e-commerce website announces a flash sale. As the sale goes live, thousands of users try to access the website simultaneously.

Cause:

• The sudden surge in traffic overwhelms the server, which cannot handle the volume of requests, leading to a 503 Service Unavailable error. Alternatively, if the website administrators are performing maintenance, they might take the server offline temporarily, resulting in this error.

  
5. 504 Gateway Timeout

• It occurs when a server doesn’t receive a response on time from the upstream server.

Example:

• You are using an online travel booking site to book a flight. The site needs to check availability with the airline's server.

Cause:

• If the airline's server takes too long to respond, the booking site's server might time out while waiting for the response, resulting in a 504 Gateway Timeout error. This usually occurs in distributed systems where one service depends on another for data.

 
6. 505 HTTP Version Not Supported

• It indicates that the server doesn’t support the HTTP protocol version used in the request.

Example:

• You are using an old web browser to access a modern web application.

Cause:

• If your browser sends a request using HTTP/1.0, but the server only supports HTTP/1.1 or HTTP/2, it will respond with a 505 HTTP Version Not Supported error.

  

HTTP 400 Series Status Codes:

• HTTP status codes in the 400 series are client error responses. These indicate that the request made by the client (e.g., a web browser) was incorrect or cannot be processed by the server. 

1. 400 Bad Request

• The server cannot understand the request due to malformed syntax.

Example:

• You try to search for a product on an e-commerce website, but you accidentally enter invalid characters in the search box. The server doesn't understand your request and returns a 400 Bad Request error.

  
2. 401 Unauthorized

• The request requires user authentication. The client must authenticate itself to get the requested response.

Example:

• You try to access your email account without logging in. The server responds with a 401 Unauthorized error, asking you to log in first.

  
3. 403 Forbidden

• It is sent when a user doesn’t have permission to access the requested page.

Example:

• You try to access a restricted page on a company's internal website without the necessary permissions. Even if you are logged in, you get a 403 Forbidden error because you don't have the right access level.

  
4. 404 Not Found

• The server cannot find the requested resource. This is the most common error.

Example:

• You click on a broken link or type in a URL that doesn't exist on a website. The server returns a 404 Not Found error because the page you're looking for cannot be found.

  
5. 405 Method Not Allowed

• The request method is known by the server but is not supported by the target resource.

Example:

• You try to submit data using a GET request instead of a POST request on a form submission page. The server responds with a 405 Method Not Allowed error.

  
6. 408 Request Timeout

• The server did not receive a complete request message within the time that it was prepared to wait.

Example:

• Your internet connection is slow, and it takes too long to send a request to a website. The server times out and returns a 408 Request Timeout error.

  
7. 429 Too Many Requests

• The user has sent too many requests in a given amount of time ("rate limiting").

Example:

• You try to log in to your account multiple times in quick succession, and the server temporarily blocks further requests, returning a 429 Too Many Requests error.

API Testing Using Postman: Part 5

 Two types of scripts in postman:

1. Pre-request script (It will run the script before execution)
2. Test script (it will run the script after execution)

Order of execution:

 Pre-request --> Request --> Response--> Test script

Execute the pre-request script and test script in 3 levels.

1. Collection level
2. Folder level
3. Request level

• If we give scripts in pre-request and test scripts at all levels. The order will be executed in the following manner.
• Collection -> Folder-> Request (until this pre-request) -> Request -> Response -> Collection -> Folder -> Test script.

Variables:

• Variables are created to reduce the effort in updating data every time. In Postman, we are also creating variables to update data every time.
• For example, some parts of the URL are common across all the requests ("https://localhost3000"). This can be stored in one variable and can be used anytime whenever we want.
• If localhost number 3000 changes also, we can update the variable, it's a one-time update and can be updated everywhere.

Types of variables:

1. Global - Accessible in Workspace
2. Collection - Accessible within the collection.
3. Environment - Accessible in all collections, but we need to switch to a particular environment.
4. Local - Accessible only within the request (Specific to Request).

API Testing Using Postman: Part 4

 Here we are validating 5 types of response in the output.

1. Status code
2. Headers
3. Cookies
4. Response time
5. Response body

• To test the above validations we have something called "Assertions" in Postman. Assertion is nothing but a validation point. To add this validation we have one library in Postman called "pm".In this, we have so many functions available. By adding some parameters to these functions we can validate the above responses.

Testing Headers:

• We can check static values present in the header.
• We are checking whether the text is present in the header as well as the text assigned to the header.

Testing Cookies:

• Every time, the cookies we get are not constant. So we are using two types of assertions. One is to check whether that cookie is present and another is text present for that cookie.

Testing Response time:

• We are checking whether the API is running in the expected time. we don't know the exact time every time, So we are giving min or max time to validate the time.

Testing Response body:

• Sometimes the response in the body is not static values, it will be dynamic sometimes. So, we are validating only the static values or content in the response body.

validating the Response body in 3 categories.

1. Validating the type of values.
2. Validating the values assigned.
3. Validating JSON Schema.

API Testing Using Postman: Part 3

HTTP vs HTTPS:

• We have 2 types of URLs. One is HTTP and the other is HTTPS.

1. HTTP(Hypertext transfer protocol) will give the data to the client without any security(without password encryption).
2. HTTPS(Hyper Text transfer protocol secure) will give the data to the client with some security (password encryption).

• URL is divided into 3 parts:

1. URL: Uniform Resource Locator
2. URI: Uniform Resource Identifier
3. URN: Uniform Resource Name

Feature & Resource:

• The feature is the term which is used in manual Testing to test some functionality. Resource is the term used in API Automation Testing referring to some functionality.

Payload: payload is the body HTTP Request and Response message.

Request payload: In the Request payload, we send the request in the request body using HTTP/HTTPS Request.

Response payload: In the response payload we will get the response in the format of HTTP Response which contains the status code, Response payload and string message.

API Testing Using Postman: Part 2

•  API helps to communicate between two different applications and also which are coded in 2 different languages.
• For example, Google developed maps that contain open-source APIs. Maps are not only used by Google but also by different applications such as whatsapp, FB, snap etc.

• API vs Webservice: API is a request which will be developed offline without using of public server and Webservice is also an API but it is deployed in the server and made available for the public.
• All Webservices are API but all APIs are not Webservices.
• An API is called a Webservice when an API is deployed in a public server and makes it available for everyone.

Two Types of API:

1. Simple Object Access Protocol(SOAP). (XML format)
2. REST(Representational State Transfer). (JSON, XML, etc.)

• SOAP is a very old tool and it is difficult to understand the request and response sometimes.
• Currently, we are using REST services. we have 4 major commands to request or to get the response.

1. GET - used to get the requested info from the Database.
2. POST - used to create a new item in DB.
3. PUT - used to update the existing item in DB.
4. DELETE - used to delete existing items from DB.

API Testing Using Postman: Part 1

Client and Server: The client is a computer or local machine which is from the user's end and the server is a place where the data is stored.

Client and server are divided into 3 categories.

• 1-Tier -  It has only 1 client and 1 server.
• 2-Tier -  It has multiple clients but contains only one server.
• 3-Tier -  It will have 3 layers.

           Client(Presentation layer)[multiple clients]

           Business logic(Application layer)[multiple API's]

           Server(Data layer)[Multiple servers]

API - Application Programming Interface.

•  Application - It works for a Web Application. It is called an Application Layer.
• Programming - we will send API requests through code which are written in programming languages(Eg: java, python etc.).
• Interface - It will act as an interface or communication barrier between client and server.

Uses of API Testing:

• Generally, we test the UI using selenium and we check whether every functionality is working or not. But, when it comes to API Testing we send a request to the server based on the request it will give the response. In the response itself, we can check whether all the functionality is working or not. 80% of the Testing is completed within less time if you know API Testing and 20% will be testing the UI elements, colour buttons etc.
• No need for UI Testing by 100%.If we perform API Testing.
• We can perform API Testing once the backend code and the APIs are ready. A gap will occur between the presentation and Application layer(it will take time to create UI). In that time, we can test our application using API's. 
• API Testing is simple and easy to learn compared to Selenium web application Testing.

9 Types of API Testing to Improve Your Website Performance

 

The Power of API Testing: How it Can Save Your Business Time and Money

 1. Core Functionality Testing: 

• This kind of testing provides access to the entire system without the need for a user interface. The functionalities of the application would be evaluated end-to-end without the need for GUI (Graphical User Interface) which helps in detecting issues that can prove to be bigger at the time of GUI testing.

2. Time and Cost Effectiveness: 

• This is usually less time-consuming when compared to GUI testing. It also requires less code for testing the functionalities thereby making it easier to set up and get faster access to test coverage. It also results in effective cost savings for the project.

3. Language-Independent: 

• The data transfer between the test platform to the applications is done utilizing XML or JSON and is completely independent of the languages used in developing the systems. The test automation suite can be developed in any language.

4. Ease of Integration with GUI:

•  API testing provides highly flexible test suites that help in easier integration with the GUI tests. For instance, before the GUI test cases are initiated, employing API test cases, we can create sample users that can act as an initial base for the GUI tests.

How to Write Effective Test Scripts for Postman API Testing

pm.test("success status", () => pm.response.to.be.success );

pm.test("Status code is 200 or 201", function () {

  pm.expect(pm.response.code).to.be.oneOf([200, 201]);

});

pm.test("Response time is less than 300ms", () => {

  pm.expect(pm.response.responseTime).to.be.below(300);

});

pm.test("Response status code contains 'Created' or 'OK'", function () {

  console.log(pm.response.status);

  pm.expect(pm.response.status).to.be.oneOf(['Created', 'OK']);

});

pm.test("Response body is not empty", function () {

    pm.expect(pm.response.text()).to.not.be.empty;

});

Maximizing Test Coverage: Tips and Tricks for Postman API Testing

 1. Test to verify the successful creation of a new request:

•   Send a POST request to the API endpoint for creating a new request with valid data.
•   Verify that the response code is 201.
•   Verify that the response body contains the correct data for the newly created request.

2. Test to verify the successful retrieval of a request:

•   Send a GET request to the API endpoint for retrieving a specific request with a valid request ID.
•   Verify that the response code is 200.
•   Verify that the response body contains the correct data for the requested request.

3. Test to verify the successful updating of a request:

•   Send a PUT request to the API endpoint for updating a specific request with valid data and a valid request ID.
•   Verify that the response code is 200.
•   Verify that the response body contains the correct data for the updated request.

4. Test to verify the successful deletion of a request:

•   Send a DELETE request to the API endpoint for deleting a specific request with a valid request ID.
•   Verify that the response code is 204.
•   Verify that the request has been deleted from the database.

5. Test to verify error handling for invalid request IDs:

•   Send a GET request to the API endpoint for retrieving a specific request with an invalid request ID.
•   Verify that the response code is 400 or 404, depending on the API's error-handling implementation.
•   Verify that the response body contains an error message indicating that the request ID is invalid.

6. Test to verify error handling for missing request data:

•   Send a POST request to the API endpoint for creating a new request with missing or invalid data.
•   Verify that the response code is 400.
•   Verify that the response body contains an error message indicating which data is missing or invalid.

7. Test to verify pagination:

•   Send a GET request to the API endpoint for retrieving a list of requests with valid pagination parameters (e.g. limit, offset)
•   Verify that the response code is 200.
•   Verify that the response body contains the correct number of requests according to the pagination parameters.

8. Test to verify authentication:

•   Send a request to the API endpoint without authentication credentials.
•   Verify that the response code is 401 or 403, depending on the API's authentication implementation.
•   Verify that the response body contains an error message indicating that authentication is required.

9. Test to verify authorization:

•   Send a request to the API endpoint with authentication credentials that do not have the required permissions for the requested action.
•   Verify that the response code is 401 or 403, depending on the API's authorization implementation.
•   Verify that the response body contains an error message indicating that the user does not have the required permissions.

10. Test to verify rate limiting:

•   Send multiple requests to the API endpoint within a short period of time with the same authentication credentials.
•   Verify that the response code for the second and subsequent requests is 429.
•   Verify that the response body contains an error message indicating that the user has exceeded the rate limit.

11. Test to verify SSL/TLS encryption:

•   Send a request to the API endpoint using HTTPS.
•   Verify that the response code is 200 or 201, depending on the request type.
•   Verify that the response is encrypted using SSL/TLS and that the appropriate certificates are being used.

12. Test to verify compatibility with different HTTP methods:

•   Send requests to the API endpoint using different HTTP methods (e.g. GET, POST, PUT, DELETE).
•   Verify that the response code and response body are correct for each request type.

  

13. Test to verify compatibility with different content types:

•   Send requests to the API endpoint using different content types (e.g. JSON, XML, form data).
•   Verify that the response code and response body are correct for each content type.

14. Test to verify handling of invalid content types:

•   Send a request to the API endpoint with an invalid content type.
•   Verify that the response code is 415.
•   Verify that the response body contains an error message indicating that the content type is not supported.

15. Test to verify handling of large requests:

•   Send a request to the API endpoint with a large payload (e.g. several MBs).
•   Verify that the response code is 413.
•   Verify that the response body contains an error message indicating that the request payload is too large.

16. Test to verify handling of concurrent requests:

•   Send multiple requests to the API endpoint simultaneously from different clients.
•   Verify that the responses for each request are correct and there are no race conditions or conflicts.

17. Test to verify handling of timeouts:

•   Send a request to the API endpoint with a timeout parameter set to a low value.
•   Verify that the response code is 408.
•   Verify that the response body contains an error message indicating that the request timed out.

18. Test to verify handling of network errors:

•   Simulate a network error (e.g. disconnecting from the network) while sending a request to the API endpoint.
•   Verify that the response code is appropriate for the error (e.g. 502, 503, or 504 depending on the error type).
•   Verify that the response body contains an error message indicating that there was a network error.

What is Authentication and Authorization in API Testing?

 

• Authentication and authorization are two main concepts in API testing that are related to the security of the API.

Authentication:

• Authentication is the process of verifying the identity of a user or a client making a request to an API.
• It involves validating the user's credentials, such as username and password, or using other authentication mechanisms like API keys, tokens, or certificates.
• The main goal of authentication is to ensure that only authorized users can access the API and its resources.

Authorization:

• Authorization, on the other hand, is the process of determining what actions a user or client can perform on the API's resources (once they have been authenticated).
• It involves verifying that the user or client has the necessary permissions or privileges to perform the requested actions, such as reading, writing, or deleting data.
• Authorization helps to ensure that users can only access the data and functions that they are allowed to, based on their role or level of access.

Good practice:

• In API testing, it is important to test both the authentication and authorization aspects of the API to ensure that they are implemented correctly and that the API is secure.

Verify response codes:

• Testing authentication may involve verifying that the API returns the expected response codes and messages when invalid or missing credentials are provided.
• Testing authorization may involve verifying that the API returns the expected response codes and messages when users try to perform unauthorized actions, such as accessing or modifying data they do not have permission to access.

APIs: The Backbone of Modern Technology and Their Everyday Applications

APIs, or application programming interfaces, are used in many different everyday scenarios. Here are some examples of APIs:

1. Social Media: Social media platforms like Facebook, Twitter, and Instagram offer APIs that allow developers to access and use their platform data, such as user profiles, posts, and comments. This allows developers to integrate social media functionality into their own applications or websites.

2. Weather Forecast: Weather forecast websites and apps use APIs to access weather data from sources like the National Weather Service or AccuWeather. This allows them to provide real-time weather updates to users.

3. E-commerce: E-commerce platforms like Amazon and eBay offer APIs that allow developers to access and use their product catalogs and other data. This allows developers to create their own e-commerce applications or integrate e-commerce functionality into their own websites.

4. Mapping and Navigation: Mapping and navigation services like Google Maps and MapQuest offer APIs that allow developers to access and use their map data and navigation features. This allows developers to create their own mapping and navigation applications or integrate mapping and navigation functionality into their own websites.

5. Travel Booking: Travel booking websites and apps use APIs to access flight, hotel, and car rental data from providers like Expedia and Travelocity. This allows them to provide real-time booking and pricing information to users.

6. Payment Processing: Payment processing services like PayPal and Stripe offer APIs that allow developers to integrate payment functionality into their own applications or websites. This allows developers to securely process payments and transactions without having to build their own payment processing system from scratch.

These are just a few examples of how APIs are used in everyday scenarios. APIs play an important role in enabling developers to build new applications, services, and products by leveraging existing data and functionality from other services and platforms.

Simplifying Your API Testing with POSTMAN's Advanced Features

1.  New: This feature is used to create a unique environment or request.
2. Import: This feature is used for importing a collection or environment.
3. Runner: This feature is used for executing automation tests.
4. Collaboration: This feature is used for inviting team members for interaction.
5. Collections: Collections are created for arranging the test suite.
6. Open New: This feature is used for opening new tabs.  
7. My Workspace: New Workspace is created individually, or as a team.
8. History: This feature is used to display past requests.
9. Request Tab: This feature is used to display the request title.
10. HTTP Request: This feature is used to display the dropdown list of various requests.  
11. Params: This feature is used for writing the required parameters for a request.
12. Authorization: To use APIs, appropriate authorization is required.
13. Save: This feature is used to save the changes made to a request.
14. Headers: You can set headers depending on the requirement of the organization.
15. Pre-request Script: This feature is used for executing the test scripts before requests.

Introduction to Postman API Testing

 Postman API:

• Postman is an API Development Environment that helps developers easily test and work with APIs.
• It is used for backend testing where we enter the end-point URL, send the request to the server, and receive the response back from the server.
• It provides an easy-to-use interface for developing, testing and debugging REST APIs.
• Postman also includes a comprehensive library of pre-defined requests and response objects, making it an ideal tool for quickly testing and prototyping APIs.

Request Methods:

• GET - Get requests are used to retrieve information from the given URL.
• POST - To send the new data to an API.
• PUT - This method is used to update the existing data.
• DELETE - This is used to remove or delete the existing data.

API test actions:

1. Verify the correct HTTP status code.
2. Verify response payload: Check valid JSON body and correct field names, types, and values - including in error responses.
3. Verify response headers: HTTP server headers have implications on both security and performance.
4. Verify correct application state: This is optional and applies mainly to manual testing, or when a UI or another interface can be easily inspected.
5. Verify basic performance sanity: If an operation was completed successfully but took an unreasonable amount of time, the test fails.

HTTP Status Codes: