0% found this document useful (0 votes)
11 views

APIs_Questions

Uploaded by

sridhar.kotha
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
11 views

APIs_Questions

Uploaded by

sridhar.kotha
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

QUANTAFIC INTERVIEW QUESTIONS

1. What are the Limits of API Usage?


• An API usage limit is essentially a safeguard put in place to make sure that an API doesn’t get
overwhelmed and continues to function normally.
In order to protect from this, APIs employ a tactic called ‘Rate Limits,” which implement a
strict set of rules on usage.
Rate limits are expressed as volume per period. Some examples:

• 1 request per second


• 30 requests per minute
• 500 requests per hour
• 5,000 requests per day
• 25,000 requests per month

2. What are some architectural styles for creating a Web API?


API Type - Description Key Features
REST (Representational State Transfer) - Relies on HTTP methods
It uses standard HTTP methods like GET, POST, PUT, and and URLs for resource
DELETE to interact with resources and relies on URLs for interaction.
resource identification. - Stateless communication
between client and server.
- Widely used and well-
established in web
development.
GraphQL - Clients request only the
It enables clients to specify the exact data they need, data they require.
resulting in more efficient and flexible data retrieval - Single endpoint for
compared to REST APIs. flexible data retrieval.
- Strongly typed schema
for clear data definition.
SOAP (Simple Object Access Protocol) - Uses XML for message
It uses XML to define message formats and typically relies format.
on HTTP or SMTP as a transport protocol. - Supports multiple
transport protocols (e.g.,
HTTP, SMTP).
- Can be complex due to
XML structure.

3. Who can use a Web API?


• Web APIs can be used by developers, third-party applications, or any system that needs to
interact with the provided services or data.
4. Common Protocols Used in API Testing?
Protocol Description
HTTP (Hypertext Transfer Protocol) Used for communication between clients
and servers, commonly used in RESTful APIs.
HTTPS (HTTP Secure) An encrypted version of HTTP, providing a
secure way to transfer data.
SOAP (Simple Object Access Protocol) A protocol used in API testing for web
services using XML messages.

5. Principles of API Test Design?


• Test the functionality of individual API endpoints separately.
• Cover various input combinations and edge cases.
• Verify error handling and responses for invalid inputs.
• Create tests that are independent, reliable, and repeatable.

6. What to Check When Performing API Testing:


• During API testing, check for:

➔ Correctness of responses based on the provided input.


➔ Handling of valid and invalid inputs.
➔ Error codes and messages returned for different scenarios.
➔ Performance under various load conditions.
➔ Security measures, such as authentication and authorization.

7. Major Challenges Faced in API Testing:


• Some challenges in API testing include:

➔ Complex API interactions and dependencies.


➔ Versioning and backward compatibility concerns.
➔ Properly setting up test data and environments.
➔ Handling rate limits and throttling during testing.
➔ Limited visibility into internal API behavior.
8. Why API Testing Is Considered the Most Suitable Form for Automation Testing:
• API testing is considered suitable for automation testing due to the following reasons:

➔ APIs offer a consistent way to interact with software, which helps tests stay unaffected by
changes in the user interface.
➔ API tests run faster and can check many different situations quickly and effectively.
➔ Automating API tests helps catch bugs early in the development process.
➔ API tests are easier to take care of and are less likely to break compared to tests that focus on
the user interface.

9. Kinds of Bugs That API Testing Would Often Find:


• API testing can often uncover bugs related to:

➔ Incorrect data handling and validation.


➔ Issues with response codes and messages.
➔ Problems with request parameters or headers.
➔ Security vulnerabilities in authentication or authorization.
➔ Performance bottlenecks and scalability concerns.

10. Status codes:


Server Side - Status Code Description
200 OK The request was successful.
201 Created The request resulted in a new resource
being successfully created.
204 No Content The request was successful, but there is no
response body to return.
400 Bad Request The server couldn't understand the request,
often due to malformed syntax or missing
parameters.
401 Unauthorized The client must authenticate itself to get the
requested response.
403 Forbidden The client does not have the necessary
permissions to access the requested
resource.
404 Not Found The requested resource could not be found
on the server.
500 Internal Server Error A generic error message, indicating that an
unexpected condition was encountered on
the server.
503 Service Unavailable The server is currently unavailable or
overloaded, and the request cannot be
fulfilled.
Client side - Status Code Description
200 OK The client request is valid and can be sent to
the server.
400 Bad Request The client request is invalid or incomplete
and should not be sent to the server.
401 Unauthorized The client needs to provide authentication
credentials before sending the request.
404 Not Found The client attempted to access a resource
that does not exist on the client-side.
500 Internal Error The client encountered an internal error or
exception while processing the request.

11. What is white box testing and black box testing?


White Box Testing Black Box Testing
What it is Testing where you know how Testing where you don’t care
the app or system works on about how the system or app
the inside. works on the inside.
Who does it Usually done by people who Usually done by testers who
understand the system’s code don’t need to understand the
,like developers. code or how the system really
works.
When it’s used Used when we want to check Used when we want to check
that each part of the system is that the system as a whole
working as it should works fine
Benefits can find hidden errors and Doesn’t require coding
improve the system’s design knowledge.

You might also like