API Testing Interview Questions

Displaying 1 - 10 of 23

What is API Mocking?

The most common term for creating simulated components is mocking, but others are also used, and partly apply to different things; stubbing, simulation, and virtualization. The basic concept is the same - instead of using an actual software component (an API in our case) – a "replacement" version of that API is created and used instead. It behaves as the original API, but lacks many of the functional and non-functional characteristics of the original component. Which term is applicable depends on the degree to which the mock-up corresponds to the actual API:

  • Stubbing: mostly a placeholder without real functionality
  • Mocking: basic functionality required for a specific testing or development purpose
  • Simulation: complete functionality for testing or development purposes
  • Virtualization: Imulation that is deployed into an operational, manageable and controllable environment

What is Representation and Representation Metadata in Rest Architectural?

A Representation of resource is Data plus Meta Data explaining about the data. Meta Data in the strict sense of Request and Response will be some header explain the format type of the Response body. For e.g. a Resource meta data may say that the content in the Response body is of Json format. This will inform Clients about how to interpret the data. 
Similarly, we can see that if we hit the Resource Identifier of equivalent XML based web service we will get the same data represented as XML. What it means is the we have changed the Resource Representation from Json to XML. On the same lines, we can even change the representation of data from XML to HTML. Hence the name of the architecture REpresentation State Transfer.

What is a Resource Identifier in the Restful architecture?

Every Resource on the Server needs to be uniquely identifiable. To do that every resource has a unique URL that can be used to get to that Resource.

URL: http://example.com/utilities/locationutil/mylocation

You can see that to access your location you have to hit the above URL. Here the Resource is your location while the unique way to access it is the Resource Identifier (URL).

Important point to note here is that a resource is not necessarily a static piece of information. For example this URL when hit by someone from United States will give their location while when hit from India will give some location from India. The location is calculated at run time and sent back to the Client. Even a dynamic information is also called a Resource.

What is Resource in the Restful architecture?

A resource in the Restful architecture is an asset that is available on a Server. A Resource can be

  • Temporal
  • Static

Temporal resource is one that keeps changing with time. For e.g. the Weather. A Static resource is one that stays constant over longer time durations. For e.g. a webpage containing some static text. Like the one you are reading now can just be a Static resource on the server.

What are Rest Architectural Elements?

Rest Architectural style defines parts of Restful service as key conceptual elements. For e.g. while we make a Rest request to a Server, the information returned by the Server is called a Resource. Let us take a quick look at the key conceptual elements in a RESTful Web Service. Its elements are:

Resource: Information stored on a Server, which can be requested by a client. It could be Weather info or may be employee details
Resource Identifier: Now that we have a resource defined, we need to uniquely identify the resource. That is actually the complete URL/
Representation: A resource is the actual data. Now this data can be represented as an XML, HTML or may be simple text. That is what is called a Representation.
Representation Metadata: In order for the Clients to specify and process a resources given in a particular Representation (XML or HTML etc) some extra data (Metadata) needs to be passed in the request.

What are REST Constrains?

Following are Rest Constrains: 

1. Client–Server Architecture style: This is the first constraint in the REST architectural style. According to this constraint an application should be modeled like a Client – Server. To relate to it, application should have the UI separate from the Data. There should be a distinct components handling Front end (UI) and the Back end (Database).

From our earlier chapter on Client-Server Architecture, UI here will act as a client and the back-end will be the server. The importance of this style of design is that Client and Server components can evolve independently. Also, most important part is that a Server can serve multiple Clients, Clients can further be on different technologies.

2. Stateless: This is the second constraint in the REST architectural style. According to this constraint a Server should not store context of the Client. Each request sent by the Client should not be treated with any information (context) from previous requests made by the same client.

The importance of this constraints is that because of it Server implementations becomes simple. It now doesn’t need to store references of clients.

Also, all the requests made by clients should be contain all the information required to service a request. We will see this constraint with example as we learn more about REST in coming tutorials.

3. Cache: This is the third constraint in the REST architectural style. According to this constraint Responses from the server should contain relevant information to tell whether the Response can be cached by the client of not. Usually this is done via a Header entry in the Response.

This constraint improves the client efficiency, for cacheable responses Client need not make requests to the server. Client can simply look into its cache for the Response. This save network bandwidth and Client processing power.

We will see this in detail as we learn more about REST in the coming tutorials.

4. Uniform Interface: The uniform interface constraint is fundamental to the design of any REST service. The uniform interface simplifies and decouples the architecture, which enables each part to evolve independently. The four guiding principles of this interface are:

Identification of resources

  • Manipulation of resources through these representations
  • Self-descriptive messages
  • Hypermedia as the engine of application state (A.K.A. HATEOAS)

5. Layered System: This is the fifth constraint in the REST architectural style. According to this constraint the system implementation should be layered. Each layer abstracting out certain functionality of the overall system. A layer should not know about the existence of other layers apart from the layers that it directly interacts with.

Layered software design is a common practice outside the realm of REST too. This constraint decreases the overall complexity of the different components within the system. As we have to deal with relatively smaller and logical cohesive pieces of functionality it becomes easier to implement layers.

6. Code on demand: This is an optional constraint that RESTful architecture imposes. According to this constraint a client can extend its functionality by downloading code from the Server This code can come in the form of Applets or Scripts. Javascript is one example of how code on demand can help clients extend their functionalities.

With the ability of a Server sending code to the Client, comes the security concerns.

What is Response Body?

 Response Body contains the resource data that was requested by the client.

Example: Response body of login functionality:

  "data": {
    "forcePassword": false,
    "deviceCode": "qHCr4kgoMtWd",
    "userid": "1234232",
    "sessionToken": "bMenbHEWywxJcyBBmGOCr3XBS",
    "expiryDate": "2020-12-16 15:17:13",
    "createdDate": null,
    "updatedDate": null,
    "platform": "web",
    "deviceIdentifier": null
  "error": null,
  "warning": null

What is Response Header?

 Just after the Status Line, Headers are displayed. Just like a Request Header, Response Header also contains zero or more Header lines. However, it is very uncommon to have zero Headers in the response. Lines just after the Status Line and before the Response Body are all Response Headers lines. Headers are used to pass additional information to the Client.

Example of Response Header:

HTTP/1.1 200 OK
Access-Control-Allow-Headers: Origin, Content-Type, sessionToken, loginId
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Origin: *
Content-Encoding: gzip
Content-Type: text/html; charset=UTF-8
Date: Tue, 17 Dec 2019 09:47:14 GMT
Server: nginx/1.10.3 (Ubuntu)
Content-Length: 220
Connection: keep-alive

What is HTTP Response?

HTTP Response is the packet of information sent by Server to the Client in response to an earlier Request made by Client. HTTP Response contains the information requested by the Client. For example, the request to Weather Web Service made in the HTTP Request tutorial will contain the weather details of the location.

Just like HTTP Request, HTTP Response also has the same structure:

  1. Status Line
  2. Headers, 0 or more Headers in the request
  3. An optional Body of the Request