This is second in the line of API Testing Questions bank. Though I do hate these kinds of question posts – I have received many requests to post questions that I generally ask in interviews related to API testing.
- How do you test ๐ฎ๐ฌ๐๐ซ ๐ซ๐จ๐ฅ๐๐ฌ ๐๐ง๐ ๐ฉ๐๐ซ๐ฆ๐ข๐ฌ๐ฌ๐ข๐จ๐ง๐ฌ ๐ข๐ง ๐ฒ๐จ๐ฎ๐ซ ๐๐๐, tell us some of the best practices that you follow for testing such user permissions in API’s.
This is a very important question I think in relation to API testing. I have written a detailed blog about this here. Although the post doesn’t mention any such best practices per se, but you will get a general idea of what tests should be done and what should be the best practices for testing these kinds of apis.
- Have you heard of the term rate-limiting? Can you explain when should we use rate limiting in API’s?
Very important concept in relation to API’s. Becomes much more important if you are exposing your api’s to public or to some external or internal clients. You can read about more here.
- Do you generate reports of the api tests that you run? What are some key attributes to include in the report.
I’ll post a detailed post on this – but mostly there can be following information
- Test Case Details: Provide a clear description of the test case.
- Test Environment: Specify the environment in which the tests were conducted, such as development, staging, or production.
- Test Execution Summary: Summarize the overall test execution, including the total number of tests executed, passed, failed, and any skipped or blocked tests.
- Test Coverage: Outline the scope of the API tests and specify which functionalities, endpoints, or API methods were covered during the testing process.
- Test Results: Present the detailed results of each test case, including the API endpoint, request payload, response status code, response time, and any relevant response data.
- Test Logs: Include relevant log entries or error messages captured during the test execution.
- Screenshots or Attachments: If applicable, include screenshots of relevant API responses, error messages, or any other supporting materials that provide visual evidence or additional context.
- Test Metrics: Provide relevant metrics, such as response times, latency, throughput, or any other performance indicators measured during the API tests.
- Have you heard of the term api gateway? What does it do?
You can read about API Gateways here in my blog post. It explains what it does and why do we need it.
- What is the difference in path param and query params?
In terms of API Testing, both path
and query
params are common ways to pass data to an endpoint. Both path parameters and query parameters can be used to make HTTP requests and retrieve data from a server, but they have some differences in how they are used and the type of data they can passed.
Path Params :
Path parameters are used to pass data as part of the URL path. They are typically used to identify a specific resource or endpoint in the server. Path parameters are denoted by a colon (:) followed by the parameter name.
For example, in the URL http://example.com/api/users/:userId
, :userId
is a path parameter that can be replaced by an actual user ID value to retrieve the data for a specific user.
Example :
For example, there is an API that returns the list of books http://abc.bookstore.com/api/books
Now you can search a book directly via the ISBN
no of the book. So if you want to directly fetch the details of the book, you can directly pass the :isbn
at the last of the URL and it will result in the book information
http://abc.bookstore.com/api/books/:isbn
like
http://abc.bookstore.com/api/books/9783161484100
You can use this in Rest-Assured in the pathParam
key

Query Params :
Query parameters, on the other hand, are used to pass data as key-value pairs in the URL query string. They are typically used to provide additional information to the server, such as sorting or filtering options.
Query parameters are denoted by a question mark (?) followed by the parameter name and value pairs. For multiple query params, they are separated by an ampersand (&).
For example, in the URL http://example.com/api/users?sort=asc&limit=10
, sort
and limit
are query parameters that can be used to sort the user data in ascending order and limit the number of results to 10.
Example :
For example, there is an API that returns the list of books http://abc.bookstore.com/api/books
Now you want to know if there is an author whose name is Rahul
and also want to see if there are 10
books that have Rahul
as author, then we can can use the query params in this scenarios like
https://abc.bookstore.com/api/books?author=Rahul&limit=10
You can use the queryParam
key in Rest Assured for passing query params

- Do we need to use POJO class and serialisation in RestAssured, when we can directly send request body in the form of String?
No, you do not necessarily need to use POJO classes and serialization in RestAssured if you prefer to send the request body as a string. RestAssured provides multiple ways to specify the request body, and one of them is to directly provide the body as a string.
However, this must be noted that this works only well when you have a very simple or small payload to send – see the code below

However, seldomly we have scenarios where we need to send simple payloads. So in the real life scenarios, the payloads that we may need to send may be very complex and big. In those scenarios, using only String
will make the code a mess.
If you have a complex request body with nested objects or arrays, it might be more convenient to use a POJO class and serialisation to generate the request body. This can make the code more readable and maintainable, especially if you have multiple requests that use the same request body format.
- Can I use cookies with rest assured – if so how can I set a cookie for a domain?
To set a cookie for a specific domain in Rest-Assured, you can use the Cookie
class and the given().cookie()
method. In the code below, we’re setting a cookie named myCookieName
with the value myCookieValue
for the domain example.com
. We also set the cookie path to "/"
so that it will be available for all pages under the domain.

- Do you know what is a HEAD request? Can you think of a scenario when HEAD request would be needed.
You can read about the HEAD
request in this post that I shared.
- Is POST a cacheable method? Is PUT a cacheable method?
POST
is actually defined in the RFC specification to be a cacheable
method under specific circumstances. There is many information on the internet that states that POST
cannot be cached. See this from the RFC documentation
Responses to POST requests are only cacheable when they include explicit freshness information (see Section 4.2.1 of [RFC7234]). However, POST caching is not widely implemented.
PUT
requests are not cacheable.
- Difference between api virtualisation and mocking?
Let’s see the difference between API Virtualisation and API Mocking –
API Virtualisation
- Virtualization creates a virtual representation of an API, mimicking its behavior, without relying on the actual API.
- It is useful when the real API is not available or still under development.
- Developers can test their applications in a controlled environment using the virtual API.
- It helps identify and fix issues early in the development process before the actual API is accessible.
- Virtualization allows for simulating specific response codes, payloads, and behaviors of the real API.
API Mocking
- Mocking involves creating a mock implementation of an API, simulating its behavior, but using an actual API.
- It is useful when the real API is available but difficult to test against (e.g., slow, unreliable, or having limited usage).
- Developers can test their applications’ behavior when interacting with the mock API.
- It helps identify and fix issues related to the application’s interaction with the API.
- Mocking allows for simulating different scenarios and conditions of the real API to test the application’s response.
- What is JSON Schema? Can I use same json schema for validating the response of two different api’s?
You can read about what JSON Schema is from this link . I think this article will give you a good idea of what JSON Schema is and why it is used.
For the second part of the question – If the response of the two different API’s are absolutely same, then yes, you can use the same json schema –
A great example would be API versioning. Let’s say there are two versions of an API endpoint
GET /users/v1/:id
GET /users/v2/:id
If there are no changes in the API response for v1
and v2
, then you can use the JSON Schema used for v1
for v2
as well.
- What is API caching and in how many ways can we cache api response.
You can read all about my understanding of cache in this post.
td:dr;
Caching can be done either server side or the client side. If done on client side, then we can use API-headers like cache-control
, etag
,pragma
to validate cached contents.