What is an API ?

An API stands for Application Programming Interface. It's essentially a set of rules and protocols that allows different software applications to communicate with each other. Imagine it as a waiter in a restaurant. You (the application) tell the waiter (API) what you want, and the waiter communicates your request to the kitchen (server). The kitchen prepares your food (the data), and the waiter brings it back to you. 

What are main differences between API and Web Service? 

APIs and web services both enable communication between software applications, but they are not the same. Here are the main differences:

1. Definition:

   • API (Application Programming Interface): A set of rules and protocols that allows different software components to communicate with each other. APIs can be used for various purposes, such as accessing web services, libraries, and operating system functions.

   • Web Service: A specific type of API that is accessible over the internet using standard web protocols, such as HTTP or HTTPS. Web services provide a way for applications to interact with each other over the web.

2. Communication Protocols:

   • API: Can use various protocols, including HTTP, HTTPS, TCP/IP, SOAP, REST, etc.

   • Web Service: Typically uses standard web protocols like HTTP and HTTPS. It can also use SOAP (Simple Object Access Protocol) or REST (Representational State Transfer) for communication.

3. Format:

   • API: Can use various data formats, such as XML, JSON, or even proprietary formats, depending on the implementation.

   • Web Service: Primarily uses XML (for SOAP-based web services) or JSON (for RESTful web services) as the data exchange format.

4. Usage:

   • API: Can be used for a wide range of purposes, including accessing libraries, operating system functions, hardware devices, and web services.

   • Web Service: Specifically designed to enable communication and data exchange between applications over the web. It is a type of API but specifically focused on web-based interactions.

5. Examples:

   • API: Operating system APIs (e.g., Windows API), library APIs (e.g., Java API), hardware APIs (e.g., DirectX API), web APIs (e.g., Google Maps API).

   • Web Service: SOAP-based web services, RESTful web services (e.g., Twitter API, Google Maps API).

What is API Testing?

API Testing is the process of evaluating an API to ensure it functions correctly, reliably, securely, and performs well. It involves checking if the API returns the expected results, handles errors gracefully, and meets performance standards. API testing helps identify issues and ensures smooth communication between software applications. 

What are the advantages of API Testing?

API Testing offers several significant advantages:

1. Early Detection of Issues: By testing APIs early in the development process, developers can identify and fix issues before they become more complex and costly to resolve.

2. Improved Quality: Ensures that APIs function correctly, leading to more reliable and stable applications. It helps in catching bugs that might not be detected during UI testing.

3. Faster Testing: API tests are generally faster than GUI tests because they bypass the user interface and directly test the underlying logic. This speeds up the testing process and reduces the overall testing time.

4. Reduced Costs: Identifying and fixing issues early in the development cycle can save time and money. The earlier a defect is found, the cheaper it is to fix it.

5. Enhanced Security: API testing includes security checks to ensure that the API is protected against potential threats and vulnerabilities, such as unauthorized access and data breaches.

6. Better Performance: Performance testing of APIs ensures they can handle expected and peak loads, providing a smoother user experience.

7. Platform Independence: API tests can be performed independently of the application’s user interface, making them useful for testing various platforms and devices.

8. Reusability: API tests can be reused across different versions of the API and across different projects, leading to consistent and efficient testing processes.

9. Thorough Validation: API testing allows for comprehensive validation of the business logic, data responses, and error handling mechanisms, ensuring the API meets all functional and non-functional requirements.

10. Automation: API testing can be easily automated, which helps in continuous integration and delivery (CI/CD) pipelines, enabling faster and more reliable releases.

What are common API protocols

There are several common protocols used in APIs to enable communication between different software systems. Here are some of the most widely used ones:

1. HTTP/HTTPS:

   • HTTP (HyperText Transfer Protocol) and HTTPS (HTTP Secure) are the foundation of any data exchange on the Web. They are commonly used for RESTful APIs. HTTPS adds a layer of security by encrypting the data being transmitted.

2. SOAP:

   • SOAP (Simple Object Access Protocol) is a protocol for exchanging structured information in the implementation of web services in computer networks. It relies on XML for its message format and usually relies on other application layer protocols, such as HTTP or SMTP, for message negotiation and transmission.

3. REST:

   • REST (Representational State Transfer) is an architectural style rather than a protocol. It uses HTTP or HTTPS for communication and is based on stateless, client-server communication. RESTful APIs often use JSON or XML to exchange data.

4. gRPC:

   • gRPC (Google Remote Procedure Call) is a high-performance, open-source framework for remote procedure calls. It uses HTTP/2 for transport, Protocol Buffers as the interface description language, and provides features such as authentication, load balancing, and more.

5. WebSocket:

   • WebSocket is a protocol that provides full-duplex communication channels over a single, long-lived connection between a client and a server. It is commonly used for real-time applications such as chat apps, live sports updates, and online gaming.

6. MQTT:

   • MQTT (Message Queuing Telemetry Transport) is a lightweight messaging protocol designed for small sensors and mobile devices, optimized for low-bandwidth and high-latency networks. It is widely used in IoT (Internet of Things) applications.

7. AMQP:

   • AMQP (Advanced Message Queuing Protocol) is an open standard application layer protocol for message-oriented middleware. It allows for reliable, secure, and scalable messaging.

8. GraphQL:

   • GraphQL is a query language for APIs and a runtime for executing those queries by using a type system you define for your data. It allows clients to request exactly the data they need, making APIs more efficient and flexible.

What are principles of an API test design?

 The five most important principles of an API test design are:

 Setup: Create objects, start services, initialize data, etc

 Execution: Steps to apply API or the scenario, including logging 

Verification: Oracles to evaluate the result of the execution 

Reporting: Pass, failed or blocked 

Clean up: Pre-test stat 

What are the common API testing types?

 While there are certainly specialty tests, and no list can be asked to be comprehensive in this realm, most tests fit broadly into these following nine categories that you should remember before attending in an API testing interview. 

1. Validation Testing

 2. Functional Testing

 3. UI testing 

4. Load testing 

5. Runtime/ Error Detection

 6. Security testing 

7. Penetration testing 

8. Fuzz testing 

9. Interoperability and

10. WS Compliance testing 

What must be checked when performing API testing? 

During the API testing process, a request is raised to the API with the known data. This way you can analyze the validation response. While testing an API, you should consider:

1. Accuracy of data 

2. Schema validation

 3. HTTP status codes 

4. Data type, validations, order and completeness

 5. Authorization checks 

6. Implementation of response timeout

 7. Error codes in case API returns,

8. Non-functional testing like performance and security testing 

What is REST?

REST stands for Representational State Transfer. It is an architectural style for designing networked applications and is often used for building web services. Here are the key principles of REST:

1. Stateless: Each request from a client to a server must contain all the information needed to understand and process the request. The server does not store any client context between requests.

2. Client-Server: The client and server are separate entities that communicate over a network. The client makes requests, and the server responds with the requested data or performs the requested action.

3. Uniform Interface: RESTful APIs use a consistent and standardized set of rules for interacting with resources. This includes using standard HTTP methods (GET, POST, PUT, DELETE) and resource representations (usually in JSON or XML format).

4. Resource-Based: In REST, everything is considered a resource, which can be identified by a unique URL. For example, a user might be a resource accessible at /users/{user_id}.

5. Stateless Communication: Each request from a client to a server must contain all the information needed to understand and process the request. The server should not store any client context between requests.

6. Layered System: REST allows for an architecture composed of multiple layers. Each layer can perform specific tasks, such as load balancing, caching, or authentication, without affecting the other layers.

7. Cacheable: Responses from the server can be marked as cacheable or non-cacheable. This allows clients to cache responses and improve performance by reducing the need for repeated requests.

What is SOAP

SOAP stands for Simple Object Access Protocol. It is a protocol for exchanging structured information in the implementation of web services. Here are some key features and characteristics of SOAP:

1. XML-Based: SOAP messages are formatted in XML (eXtensible Markup Language), making them platform-independent and easy to read.

2. Transport Protocols: SOAP can be used over various transport protocols, including HTTP, HTTPS, SMTP, TCP, and more. However, HTTP and HTTPS are the most commonly used protocols for SOAP.

3. Extensibility: SOAP is designed to be extensible, allowing developers to create their own custom headers and use existing ones to add new features without breaking existing functionality.

4. Message Structure: A typical SOAP message consists of the following parts:

   • Envelope: The root element that defines the XML document as a SOAP message.

   • Header: An optional element that contains metadata and additional information for processing the message.

   • Body: The main part of the message that contains the actual data or request/response information.

   • Fault: An optional element that provides information about errors that occurred while processing the message.

5. Standardization: SOAP is a standardized protocol maintained by the World Wide Web Consortium (W3C), ensuring compatibility and interoperability between different systems and platforms.

6. Security: SOAP supports various security protocols and standards, such as WS-Security, which provides end-to-end security for SOAP messages.

7. Error Handling: SOAP has built-in error handling mechanisms, allowing the sender to receive detailed error information when something goes wrong.

SOAP is often used in enterprise environments where reliability, security, and interoperability are critical. It is well-suited for complex transactions and scenarios that require robust messaging capabilities.

What are the differences between SOAP and REST?

SOAP and REST are two popular approaches for building web services, but they have some key differences:

1. Protocol:

   • SOAP: SOAP (Simple Object Access Protocol) is a protocol. It defines a strict set of rules and standards for structuring messages and communication.

   • REST: REST (Representational State Transfer) is an architectural style. It provides guidelines for creating scalable web services, but it doesn't enforce strict standards or protocols.

2. Data Format:

   • SOAP: Uses XML (eXtensible Markup Language) exclusively for message format.

   • REST: Can use various data formats, including JSON (JavaScript Object Notation), XML, HTML, and plain text. JSON is most commonly used due to its simplicity and ease of use.

3. Transport Protocols:

   • SOAP: Can be used over multiple transport protocols, such as HTTP, HTTPS, SMTP, TCP, and more. However, HTTP and HTTPS are most common.

   • REST: Primarily uses HTTP or HTTPS for communication.

4. Message Structure:

   • SOAP: Has a rigid and predefined message structure, including an envelope, header, and body. This structure makes SOAP messages heavier and more complex.

   • REST: Has a more flexible message structure and is less complex. RESTful APIs typically use HTTP methods (GET, POST, PUT, DELETE) and rely on standard URL conventions.

5. Performance:

   • SOAP: Can be slower and more resource-intensive due to its XML format and additional overhead. It's suitable for complex transactions and scenarios requiring strong security and reliability.

   • REST: Generally faster and more lightweight due to its simplicity and use of JSON. It's well-suited for web and mobile applications where performance is critical.

6. Security:

   • SOAP: Offers built-in security features like WS-Security, which provides end-to-end security for messages, including encryption and authentication.

   • REST: Relies on standard web security measures, such as HTTPS, OAuth, and API keys. It doesn't have built-in security standards like SOAP.

7. Statefulness:

   • SOAP: Can maintain state between requests, making it suitable for scenarios where stateful operations are required.

   • REST: Is stateless, meaning each request from a client to a server must contain all the information needed to understand and process the request. This makes REST more scalable.

8. Use Cases:

   • SOAP: Commonly used in enterprise environments for complex transactions, such as banking and telecommunication systems, where strong security and reliability are essential.

   • REST: Widely used for web and mobile applications, where simplicity, performance, and scalability are important.

In summary, SOAP is a protocol with strict standards, making it suitable for complex and secure transactions. REST is an architectural style that is more flexible, lightweight, and better suited for web and mobile applications.

What is a HTTP Response?

HTTP (Hypertext Transfer Protocol) response is a message sent by a server to a client, typically a web browser, in response to an HTTP request made by the client. The response contains information about the status of the request and may also include the requested data.

An HTTP response consists of three main parts:

1. Status Line: This indicates the status of the HTTP request. It includes the HTTP version, a status code, and a reason phrase. For example:
   HTTP/1.1 200 OK

2. Headers: These provide additional information about the response, such as the content type, server information, and cache control. Headers are key-value pairs, separated by a colon, like this:
   Content-Type: application/json

3. Body: This contains the actual data being sent back to the client. The content of the body depends on the type of request made and can include HTML, JSON, XML, images, or other data formats. For example:
   
   Here's an example of an HTTP response:

HTTP/1.1 200 OK

Date: Fri, 30 Jun 2017 13:50:11 GMT

Connection: close

Content-Type: application/json

{

    "projects": {

        "project": [

            {

                "id": 1,

                "name": "A New Project",

                "position": 0,

                "state": "active"

            }

        ]

    }

}

The status code "200 OK" indicates that the request was successful, and the body contains a JSON payload with the project information

What is a HTTP Status code?

An HTTP status code is a three-digit number that the server sends back in response to an HTTP request made by a client (such as a web browser). It indicates the status of the request and whether it was successful, encountered an error, or requires additional action. Here’s a quick rundown of the main categories and some common status codes:

1. 1xx: Informational

   • 100 Continue: The server has received the request headers and the client should proceed to send the request body.

2. 2xx: Success

   • 200 OK: The request was successful, and the server is returning the requested data.

   • 201 Created: The request was successful, and a new resource was created as a result.

3. 3xx: Redirection

   • 301 Moved Permanently: The requested resource has been permanently moved to a new location.

   • 302 Found: The requested resource has been temporarily moved to a different location.

4. 4xx: Client Error

   • 400 Bad Request: The server could not understand the request due to invalid syntax.

   • 401 Unauthorized: Authentication is required and has failed or has not been provided.

   • 404 Not Found: The requested resource could not be found on the server.

5. 5xx: Server Error

   • 500 Internal Server Error: The server encountered an unexpected condition that prevented it from fulfilling the request.

   • 503 Service Unavailable: The server is currently unable to handle the request due to temporary overload or maintenance.

What is JSON

JSON (JavaScript Object Notation) is a lightweight data-interchange format that is easy for humans to read and write and easy for machines to parse and generate. It is based on a subset of JavaScript and is commonly used to transmit data between a server and a web application.

JSON represents data as key-value pairs, where each key is a string, and the value can be a string, number, boolean, null, array, or another JSON object. Here's an example of a JSON object:

{

  "name": "John Doe",

  "age": 30,

  "isStudent": false,

  "courses": ["Math", "Science", "History"],

  "address": {

    "street": "123 Main St",

    "city": "Anytown",

    "state": "CA"

  }

}

In this example:

• "name" is a key with a string value "John Doe".

• "age" is a key with a numeric value 30.

• "isStudent" is a key with a boolean value false.

• "courses" is a key with an array value ["Math", "Science", "History"].

• "address" is a key with an object value that contains its own set of key-value pairs.

What is XML

XML (Extensible Markup Language) is a versatile, human-readable and machine-readable text format used to structure data. It's similar to HTML but is designed to be both human- and machine-readable, allowing data to be stored and transported efficiently.

Here’s an example of an XML document:

<?xml version="1.0" encoding="UTF-8"?>

<note>

  <to>Jane</to>

  <from>John</from>

  <heading>Reminder</heading>

  <body>Don't forget our meeting tomorrow!</body>

</note>

In this example:

• <?xml version="1.0" encoding="UTF-8"?> is the XML declaration, which specifies the XML version and character encoding.

• <note> is the root element, which contains all other elements.

• <to>, <from>, <heading>, and <body> are child elements, each with opening and closing tags (<tagname> and </tagname>).

• The text between each pair of tags is the element's content.

Key Features of XML:

1. Structure: XML documents are hierarchical and consist of nested elements. This structure makes it easy to represent complex data.

2. Flexibility: XML is extensible, meaning you can create your own custom tags to suit your needs.

3. Self-descriptive: The tags provide meaningful names for the data they contain, making it easy to understand the structure and content.

4. Interoperability: XML is platform-independent and can be used to exchange data between different systems and applications.

5. Validation: XML documents can be validated against a schema (like DTD or XSD) to ensure they adhere to a defined structure and set of rules.

What are HTTP Headers

HTTP headers are pieces of metadata sent along with an HTTP request or response. They provide additional information about the request or response, such as content type, encoding, cookies, and more. Here's a rundown of the most important headers and their purposes:

Common HTTP Request Headers

1. Host: Specifies the domain name of the server and the TCP port number on which the server is listening (e.g., Host: www.example.com).

2. User-Agent: Contains information about the client software (e.g., web browser) making the request (e.g., User-Agent: Mozilla/5.0).

3. Accept: Indicates the MIME types that the client can process (e.g., Accept: text/html,application/json).

4. Content-Type: Specifies the media type of the request body (e.g., Content-Type: application/json).

5. Authorization: Contains credentials for authenticating the client with the server (e.g., Authorization: Basic Ym9iOmRvYmJz).

Common HTTP Response Headers

1. Content-Type: Indicates the media type of the response body (e.g., Content-Type: application/json).

2. Content-Length: Specifies the size of the response body in bytes (e.g., Content-Length: 348).

3. Set-Cookie: Used to send cookies from the server to the client (e.g., Set-Cookie: sessionId=abc123; Path=/; HttpOnly).

4. Cache-Control: Controls caching behavior (e.g., Cache-Control: no-cache).

5. Server: Identifies the server software handling the request (e.g., Server: Apache/2.4.1).

Widely used HTTP methods

HTTP (HyperText Transfer Protocol) methods are used to define the actions that can be performed on resources in a web service. Here are the most widely used HTTP methods:

1. GET:

   • Purpose: Retrieve data from a server.

   • Usage: Fetch a specific resource or a list of resources.

   • Example: GET /users - retrieves a list of users.

2. POST:

   • Purpose: Submit data to a server to create a new resource.

   • Usage: Create a new resource or submit data for processing.

   • Example: POST /users - creates a new user.

3. PUT:

   • Purpose: Update an existing resource or create a resource if it doesn't exist.

   • Usage: Update an entire resource.

   • Example: PUT /users/123 - updates the user with ID 123.

4. PATCH:

   • Purpose: Partially update an existing resource.

   • Usage: Update specific fields of a resource.

   • Example: PATCH /users/123 - updates specific fields of the user with ID 123.

5. DELETE:

   • Purpose: Remove a resource from the server.

   • Usage: Delete a specific resource.

   • Example: DELETE /users/123 - deletes the user with ID 123.

6. HEAD:

   • Purpose: Retrieve the headers for a resource without the response body.

   • Usage: Check the metadata of a resource, such as content type and length.

   • Example: HEAD /users - retrieves the headers for the users resource.

7. OPTIONS:

   • Purpose: Describe the communication options for a resource.

   • Usage: Discover the allowed HTTP methods for a resource.

   • Example: OPTIONS /users - retrieves the allowed methods for the users resource.

8. CONNECT:

   • Purpose: Establish a tunnel to the server.

   • Usage: Used for SSL tunneling through an HTTP proxy.

   • Example: CONNECT example.com:443 - establishes a tunnel to the server.

9. TRACE:

   • Purpose: Perform a message loop-back test along the path to the target resource.

   • Usage: Used for diagnostic purposes to see the path a request takes.

   • Example: TRACE /users - performs a trace for the users resource.