API – Testing Overview & Detailed

Notes
Table of Contents
1. What is an API?........................................................................................................ 2
1.1. Key Characteristics of APIs:................................................................................... 2
1.2. Examples:......................................................................................................... 2
2. Why Use an API?...................................................................................................... 2
2.1. Benefits of Using APIs:......................................................................................... 2
2.2. Use Cases:........................................................................................................ 3
3. Difference Between API and Web Services......................................................................3
3.1. Detailed Comparison:.......................................................................................... 3
4. Different Types of APIs............................................................................................... 3
4.1. Open/Public APIs:.............................................................................................. 3
4.2. Partner APIs:..................................................................................................... 3
4.3. Internal/Private APIs:.......................................................................................... 4
4.4. Composite APIs:................................................................................................. 4
5. API Testing Tools....................................................................................................... 4
5.1. Detailed Overview of Popular Tools:........................................................................4
6. API Testing Criteria.................................................................................................... 5
6.1. Key Criteria for API Testing:................................................................................... 5
7. Detailed Process of API Testing.................................................................................... 5
7.1. API Testing Steps:............................................................................................... 5
8. Different Types of API Testing...................................................................................... 6
8.1. Detailed Types of API Testing:................................................................................ 6
9. Test Scenarios for Manual API Testing..........................................................6
9.1. Break End Point:................................................................................................ 7
9.2. Break Method:.................................................................................................. 7
9.3. Without Token:.................................................................................................. 7
9.4. Break Parameters:.............................................................................................. 7
9.5. Break Payload:................................................................................................... 7
9.6. Performance Testing:.......................................................................................... 7
10. HTTP Status Codes Overview................................................................................... 8
11. Other Related Concepts.......................................................................................... 9
12. Conclusion........................................................................................................... 9

1. What is an API?
An Application Programming Interface (API) is a defined set of rules and protocols that allows different
software components or applications to communicate and interact with each other. APIs enable
developers to access certain features or data of a system without needing to understand the underlying
codebase. APIs can be public (open) for external developers or private for internal use within an
organization.

1.1. Key Characteristics of APIs:

 Standardized Communication: APIs use standard protocols (HTTP/HTTPS, REST, SOAP) to
facilitate communication.
 Abstraction: APIs abstract the internal workings of a system and provide a simplified interface
for interacting with it.
 Modularity: APIs allow developers to build modular software, making applications more
manageable and scalable.

1.2. Examples:
 RESTful APIs: Widely used due to their simplicity and compatibility with HTTP methods (GET,
POST, PUT, DELETE).
 SOAP APIs: Use XML for messaging and include stricter security and transactional compliance.

2. Why Use an API?

APIs are essential for modern software development due to their ability to connect disparate systems
and enable them to work together harmoniously.

2.1. Benefits of Using APIs:

 Efficiency: Developers can leverage pre-existing functions and services to avoid rebuilding
features from scratch, speeding up the development process.
 Interoperability: APIs provide a standardized way for different software platforms to
communicate, leading to better integration.
 Security: APIs expose only specific endpoints, safeguarding sensitive parts of the application.
 Innovation: They allow developers to build new applications on top of existing systems, fostering
innovation and expansion of services.
 2.2. Use Cases:
 Social Media Integration: Websites use APIs from platforms like Facebook or Twitter for user
authentication and sharing content.
 Payment Processing: E-commerce websites utilize payment gateway APIs like Stripe or PayPal for
transactions.
 Weather Applications: These apps use APIs from weather service providers to fetch real-time
data.

3. Difference Between API and Web Services

While APIs and web services are closely related, they are not the same.

3.1. Detailed Comparison:

 Definition:
 API: A set of protocols and tools for building application software. Can use different
communication protocols (HTTP, WebSocket, etc.).
 Web Service: A type of API that must be accessed over a network and uses standard
protocols like HTTP, SOAP, or XML-RPC.
 Protocol Support:
 API: Can use any protocol (e.g., REST, SOAP, RPC, WebSocket).
 Web Service: Primarily uses HTTP, SOAP, or XML-RPC.
 Data Format:
 API: Can use JSON, XML, or other formats.
 Web Service: Commonly uses XML.
 Accessibility:
 API: Not all APIs are web services, but all web services are APIs.
 Web Service: Must be network-based.

4. Different Types of APIs

APIs come in various forms to meet specific needs. Each type serves a unique purpose and caters to
different scenarios.

4.1. Open/Public APIs:

 Definition: Available for external use by any developer. These APIs are typically free or
available under a licensing agreement.
 Examples: Google Maps API, Twitter API.
 Purpose: Enhance user experiences by integrating third-party functionalities.

4.2. Partner APIs:

 Definition: Shared with specific partners who have a business relationship with the provider.
 Examples: APIs for strategic business partners in the travel industry for booking flights or
hotels.
  Purpose: Enhance cooperation and integration between partnered businesses.

4.3. Internal/Private APIs:

 Definition: Used within an organization to improve internal processes and services.
 Examples: APIs that connect a company's HR management system with its payroll system.
 Purpose: Improve efficiency and streamline internal workflows.

4.4. Composite APIs:

 Definition: Combine multiple API calls into one, allowing complex operations with a single
request.
 Examples: E-commerce applications that fetch product details, user reviews, and pricing in
one request.
 Purpose: Improve performance and simplify client requests.

5. API Testing Tools

There is a range of tools available for API testing, each with unique features that cater to different testing
needs.

5.1. Detailed Overview of Popular Tools:

 Postman:
 Features: User-friendly interface, automation capabilities, support for REST and SOAP.
 Usage: Ideal for manual and automated testing, collaboration through shared
workspaces.
 SoapUI:
 Features: Advanced testing of SOAP and RESTful services, assertion wizard, and scripting
support.
 Usage: Suitable for more complex API testing scenarios, including web services.
 Insomnia:
 Features: Simple interface, support for GraphQL, easy to use for debugging.
 Usage: Quick API testing and development workflows.
 JMeter:

 Features: Primarily used for performance testing, also supports functional API testing.

 Usage: Load testing for APIs to simulate heavy traffic.

 Swagger:
 Features: API documentation and testing, interactive UI for running test requests.
 Usage: Useful for verifying API specifications and functionality.
 Katalon Studio:
 Features: Comprehensive platform with automated and manual testing capabilities.
 Usage: Used for test automation that includes API, web, and mobile testing.
 6. API Testing Criteria
Ensuring that APIs perform as expected involves several criteria that guide the testing process.

6.1. Key Criteria for API Testing:

 Validation of Response:
 Data Accuracy: Verify that the response data matches the expected results.
 Data Types: Ensure that returned data types are as specified (e.g., strings, integers).
 Performance:
 Latency: Measure the response time for API calls under different loads.
 Throughput: Ensure that the API can handle the desired number of requests per
second.
 Security:
 Authentication: Verify if the API enforces authentication mechanisms like OAuth,
API keys, or JWT tokens.
 Data Encryption: Check if sensitive data is encrypted in transit.
 Error Handling:
 Robustness: Test how the API handles invalid inputs and scenarios with detailed
error messages.
 Consistent Error Codes: Ensure that the API returns consistent status codes and
messages for similar types of errors.
 Documentation Accuracy:
 Endpoint Details: Ensure that all endpoints are well-documented with example
requests and responses.
 Parameters: Verify descriptions of required and optional parameters.
 Security Compliance:
 Authorization Checks: Confirm that users with different roles have appropriate access levels.
 Vulnerability Assessments: Test for potential security vulnerabilities, such as SQL injection or
cross-site scripting.

7. Detailed Process of API Testing

API testing follows a systematic process to validate its functionality, performance, security, and reliability.

7.1. API Testing Steps:

 Review API Specifications:
o Understand the API's intended functionality and data structures.
 Set Up the Test Environment:
o Use tools like Postman or SoapUI for manual testing.
 Define Input Parameters and Request Types:
o Specify data inputs, HTTP methods (GET, POST, PUT, DELETE), and headers.
 Create Test Cases:
o Include positive, negative, and edge case scenarios.
  Execute Test Cases:
o Send requests and capture responses for analysis.
 Validate Responses:
o Check status codes, payloads, response times, and headers.
 Document Findings:
o Record test results and any discrepancies observed.
 Report and Iterate:
o Share findings with the development team for bug fixes and improvements.

8. Different Types of API Testing

Various types of testing can be conducted on APIs to ensure thorough verification of all aspects.

8.1. Detailed Types of API Testing:

 Functional Testing:
o Purpose: Ensure the API works as intended with correct input and output.
o Process: Validate the functionality of endpoints using valid and invalid data.
 Load/Performance Testing:
o Purpose: Evaluate how the API performs under high traffic.
o Process: Simulate peak load conditions using tools like JMeter or LoadRunner.
 Security Testing:
o Purpose: Ensure the API is secure against unauthorized access and threats.
o Process: Test authentication, authorization, and data protection mechanisms.
 Penetration Testing:
o Purpose: Simulate real-world attacks to find potential vulnerabilities.
o Process: Use tools like Burp Suite or manual methods to identify weaknesses.
 Validation Testing:
o Purpose: Confirm that the API meets business and technical requirements.
o Process: Verify responses, performance, and standards compliance.
 Mocking and Virtualization:
o Purpose: Simulate API behavior when the real API is not available.
o Process: Use tools like WireMock to create mock responses.
 Contract Testing:
o Purpose: Verify that the contract between the consumer and provider is upheld.
o Process: Ensure the response structure matches predefined contracts.
 Integration Testing:
o Purpose: Test the interaction between APIs and other services.
o Process: Validate data flow and combined functionalities.
 9. Test Scenarios for Manual API
Testing
The following scenarios are crucial for effectively testing APIs, whether through manual methods or
automation:

9.1. Break End Point:

This scenario involves altering the endpoint to an incorrect value to evaluate the API's response. The
expected outcome is a 404 Not Found error.

 Example:
o Valid URL: https://test.com/api/test
o Invalid URL: https://test.com/api/test _invalid

9.2. Break Method:

In this test, the user attempts to access the correct endpoint but utilizes an invalid HTTP method. The
anticipated response is a 405 Method Not Allowed error.

 Example:
o Correct Method: URL: https://test.com/api/test; Method: POST
o Incorrect Method: URL: https://test.com/api/test; Method:
GET/PUT/PATCH/OPTION/HEAD/DELETE (any method other than POST)

9.3. Without Token:

This scenario tests the API's behavior when triggered without a valid authentication token. The expected
response is a 401 Unauthorized error. The user may set the token to 'No Auth' or supply an incorrect or
expired Bearer token.

9.4. Break Parameters:

This scenario encompasses both positive and negative testing of API parameters.

 Positive Cases (Expecting 200 for GET and 201 or 202 for POST):
o All Parameters: The user should include both mandatory and optional parameters in the
API request.
o Only Mandatory Parameters: The user should provide only the mandatory parameters.
 Negative Cases (Expecting 422 Unprocessable Entity):
o With Each Mandatory Parameter: The user should test the API by omitting each
mandatory field one at a time.
o Data Type Validation: The user should input invalid data types in the parameters to
verify error handling.

9.5. Break Payload:

In this scenario, the user modifies the values associated with keys in the API input payload, testing both
data type and length constraints to ensure the API responds correctly to these variations.
 9.6. Performance Testing:
All triggered APIs should respond within one second. If the response time exceeds this limit, it should be
documented as a defect

10. HTTP Status Codes Overview

 1xx (Informational):
 100 Continue: The initial part of a request has been received, and the client can
continue.
 101 Switching Protocols: Server switching protocols as requested.
 102 Processing: Server has received and is processing the request but no response is
available yet.
 2xx (Success):
 200 OK: Standard response for a successful request.
 201 Created: Request has been fulfilled, and a new resource is created.
 202 Accepted: Request accepted but not processed yet.
 203 Non-Authoritative Information: The returned meta-information is not from the
origin server.
 204 No Content: The server successfully processed the request, but no content is
returned.
 205 Reset Content: Instructs the user agent to reset the document view.
 206 Partial Content: Partial response due to range header sent by the client.
 3xx (Redirection):
 300 Multiple Choices: Multiple options for the resource are available.
 301 Moved Permanently: Resource has been permanently moved to a new URL.
 302 Found: Resource temporarily located at a different URL.
 303 See Other: Response can be found under another URL using GET.
 304 Not Modified: Indicates that the cached version of the resource is still valid.
 307 Temporary Redirect: Resource temporarily moved to a different URL without altering
request method.
 308 Permanent Redirect: Similar to 301 but the method remains the same.
 4xx (Client Errors):
 400 Bad Request: The server could not understand the request due to invalid syntax.
 401 Unauthorized: Authentication is required and has failed or not been provided.
 402 Payment Required: Reserved for future use; indicates that payment is required.
 403 Forbidden: The server understood the request but refuses to authorize it.
 404 Not Found: The server cannot find the requested resource.
 405 Method Not Allowed: Request method is known but has been disabled and cannot
be used.
 406 Not Acceptable: The server cannot produce a response matching the list of
acceptable values.
 407 Proxy Authentication Required: Client must authenticate with a proxy.
 408 Request Timeout: Server timed out waiting for the request.
  409 Conflict: The request could not be processed because of a conflict.
 410 Gone: The resource requested is no longer available.
 411 Length Required: Server requires the Content-Length header.
 412 Precondition Failed: Precondition given in request evaluated to false.
 413 Payload Too Large: Request entity is larger than limits defined by the server.
 414 URI Too Long: The URI requested by the client is longer than the server can
interpret.
 415 Unsupported Media Type: Media format of the request is not supported by the
server.
 416 Range Not Satisfiable: Range specified by the Range header cannot be fulfilled.
 417 Expectation Failed: Server cannot meet the requirements of the Expect header.
 422 Unprocessable Entity: Datatype or field value is not given properly.
 5xx (Server Errors):
 500 Internal Server Error: Generic server error message.
 501 Not Implemented: Server does not support the functionality required.
 502 Bad Gateway: Server received an invalid response from the upstream server.
 503 Service Unavailable: The server is not ready to handle the request.
 504 Gateway Timeout: Server acting as a gateway timed out waiting for the upstream
server.
 505 HTTP Version Not Supported: Server does not support the HTTP protocol version
used in the request.
 506 Variant Also Negotiates: Server has an internal configuration error.
 507 Insufficient Storage: Server unable to store the representation needed to complete
the request.
 508 Loop Detected: Server detected an infinite loop while processing the request.
 510 Not Extended: Further extensions to the request are required for the server to fulfill
it.
 511 Network Authentication Required: Client needs to authenticate to gain network
access.

11. Other Related Concepts

 Rate Limiting: Mechanism to control the number of requests a client can make in a given period.
 Caching: Storing API responses temporarily to reduce server load and improve response time.
 API Throttling: Regulating the number of API calls a client can make to prevent abuse.
 Latency and Response Time: Measuring the time taken by the API to respond.
 OAuth and Token-Based Authentication: Common methods for securing APIs and managing
access control.
 Cross-Origin Resource Sharing (CORS): Mechanism allowing controlled access to resources from
different origins.
 API Documentation and Specification: Ensuring clear and detailed documentation for better
developer understanding and integration.
 12. Conclusion
Manual API testing is vital for verifying that APIs deliver the expected functionality, reliability,
performance, and security. Understanding every aspect of API testing helps ensure robust application
development, ultimately leading to seamless integrations and higher quality software. A comprehensive
grasp of HTTP status codes, testing techniques, and security measures is essential for proficiently testing
APIs in any environment.