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 

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.

HTTP Cookies vs Sessions vs Tokens – Web Authentication & Authorization Explained

HTTP cookies:

• HTTP cookies are small pieces of data that are sent by the server to the client, and stored by the browser.
• They can be used to store user preferences, track user behavior, or maintain user sessions.
• For authentication and authorization, cookies can store a unique identifier that links the user to a server-side record of their credentials and roles.
• The browser sends the cookie back to the server with every request, so the server can verify the user's identity and permissions.
• However, cookies have some drawbacks, such as being vulnerable to theft, forgery, or cross-site scripting attacks, and being limited by size and number.

HTTP sessions:

• HTTP sessions are a way of maintaining stateful communication between the client and the server, despite HTTP being a stateless protocol.
• Sessions use cookies or other methods to store a session ID on the client side and associate it with a server-side data structure that contains the user's information and state.
• Sessions can store more data than cookies and can be more secure if the session ID is encrypted or regenerated frequently.

HTTP tokens:

• HTTP tokens are another way of implementing stateless authentication and authorization, without relying on cookies or sessions.
• Tokens are self-contained pieces of data that encode the user's identity, permissions, and other claims, and are signed by the server using a secret key or a public-private key pair.
• Tokens are sent by the server to the client, and stored by the browser in local storage or memory.
• The client sends the token back to the server with every request, and the server validates the token's signature and payload.
• Tokens can be more flexible, portable, and scalable than cookies or sessions, and can support cross-domain and cross-origin requests.

Cookie-based vs Token-based authentication:

• Cookie-based and token-based authentication are two common approaches to implementing web authentication and authorization, and each one has its own pros and cons.
• Cookie-based authentication relies on the server to manage the user's session and state and uses cookies to store and transmit the session ID.
• Token-based authentication relies on the client to store and transmit the user's information and claims and uses tokens to encode and sign them.
• Cookie-based authentication can be simpler to implement, more compatible with browsers, and easier to revoke.
• Token-based authentication can be more efficient, secure, and flexible, and support more scenarios and platforms.

How to choose the best method

• When deciding which method is the best for web authentication and authorization, there is no definite answer as it depends on various factors such as the type, size, and complexity of the web application, the security and performance requirements, user experience and expectations, and available technologies and standards. Generally speaking, cookies should be used if stateful communication between the client and server is needed or if existing browser features and frameworks that support cookies are to be leveraged. Tokens should be used if stateless communication between the client and server is necessary or if cross-domain and cross-origin requests need to be enabled. A combination of cookies and tokens can be used to achieve a balance between statefulness and statelessness or to enhance the security and functionality of your web application.
• Stateless Protocol does not require the server to retain the server information or session details. Stateful Protocol requires the server to save the status and session information.

Understanding HTTP Headers: Types, Examples & Their Role in Web Communication

HTTP Request and Response objects consist of a body and header. While the body in the Response holds the data message (HTML, JSON) or form fields in the Request, the headers let the client and the server pass essential information about each other.

Headers can be grouped into four categories by their context:

• General headers contain information that is relevant for both request and Response, but no information about the data in a body.
• Request headers hold information about the client and requested resources.
• Response headers include server details, like time, location, and configuration.
• Entity header informs the browser about the type and body of the resource.

Let’s inspect more in detail. Go to the webpage https://madurai.nic.in/, open the console > Network tab, and select the document to inspect headers. You will likely see the headers divided into General, Request, and Response.

General group consist of the following information:

• Request URL: https://madurai.nic.in/wp-admin/admin-ajax.php
• Request Method: POST
• Status Code: 200 OK
• Remote Address: 164.100.225.214:443 (The IP address of the server)

Request Headers include the following properties:

• Accept: / (Accept any content type)
• Accept-Encoding: gzip, deflate, br, zstd (An algorithm, such as compression that is used on the recourse sent back.)
• Accept-Language: en-US, en (Hints the server about the expected language)
• Connection: keep-alive (Controls how long connection should stay open)
• User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36 (Lets server to identify the characteristics of the application, OS, vendor, and versions)

Response Headers include:

• Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 (Set the instruction for caching. Other setting types: no-cache, no-store, no-transform)
• Content-Encoding: Specifies the compression algorithm used for the response body
• Content-Length: 17 (The size of the recourse in bytes)
• Content-Type: application/json; charset=UTF-8 (The resource type received. The current type is a JSON document.)
• Date: Tue, 09 Jul 2024 06:57:27 GMT (The time when the message was created)
• Expires: Wed, 11 Jan 1984 05:00:00 GMT (Sets the date when the relevant content will no longer be new/fresh)
• Server: Specifies the software used by the server at the time of the sent Response

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

 

Exploring the Common API Terminology You Need to Know

1. REST (Representational State Transfer): An architectural style for designing networked applications, typically using HTTP as the underlying protocol.
2. SOAP (Simple Object Access Protocol): A protocol for exchanging structured information in web services using XML-based messages.
3. JSON (JavaScript Object Notation): A lightweight data-interchange format that is easy for humans to read and write, and easy for machines to parse and generate.
4. OAuth (Open Authorization): An open standard for authorization that allows users to grant access to their protected resources without sharing their credentials.
5. SDK (Software Development Kit): A set of tools, libraries, and documentation that developers use to build applications for a specific platform or programming language.
6. SDK Client: A software component or library that provides an interface for interacting with an API from within an application.
7. API client: A program or tool that interacts with an API on behalf of a user or system.
8. API key: A secret token or credential to authenticate a user or system when accessing an API.
9. Authentication: The process of verifying the identity of a user or system attempting to access an API.
10. Authorization: The process of determining whether a user or system has permission to access a specific resource or perform a particular action.
11. Endpoint: A URL that represents a specific resource or action within an API.
12. HTTP verb/method: The type of request being made (e.g., GET, POST, PUT, DELETE) that determines the action to be taken on a resource.
13. Rate Limiting: The process of restricting the number of requests a client can make to an API within a given time period to prevent abuse or ensure fair usage.
14. Webhooks: A mechanism for receiving real-time notifications from an API by sending HTTP requests to a specified URL when a specific event occurs.
15. CORS (Cross-Origin Resource Sharing): A mechanism that allows resources (e.g., fonts, JavaScript) on a web page to be requested from another domain outside the domain from which the resource originated.
16. API Gateway: A server that acts as an entry point for client requests and provides various features such as routing, authentication, and rate limiting for backend APIs.
17. Bearer Token: A type of access token used in authentication, where the token is presented by the client to access protected resources.
18. GraphQL (Graph Query Language): A query language and runtime for APIs that provide a flexible and efficient approach to request and manipulate data.
19. Versioning: The practice of assigning a version number to an API to manage changes, additions, or removals of functionality over time.
20. Payload: The data transmitted in a request or response body, typically in formats like JSON or XML.
21. Pagination: The process of dividing a large data set into smaller pages or chunks to improve performance and limit the amount of data transferred in a single response.
22. Content-Type: An HTTP header that specifies the media type of the data being sent or received in a request or response.
23. API Documentation: Comprehensive and structured information about an API, including endpoints, request/response formats, parameters, and example usage.
24. API Key: A unique identifier or token provided to a client application for authentication and authorization purposes when making API requests.
25. Query parameter: A way to pass additional information to an API endpoint through the URL query string.
26. Asynchronous API: An API design pattern where the client can send a request to the server and receive a response at a later time, without blocking the client's execution until the response is received.

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.