10 Advanced REST API Interview Questions for Developers

If you’re new to API testing, you might want to start with our beginner’s guide on What is API Endpoint and How to Get Started. Once you’re familiar with the fundamentals, these 10 advanced REST API interview questions will help you prepare for real-world scenarios and technical discussions

1. What do you understand by RESTful Web Services?

RESTful web services follow the REST architecture, using HTTP for communication. They're lightweight, scalable, and facilitate communication between applications in different languages. Clients access server resources via HTTP requests, which include headers, bodies, and receive responses with data and status codes.

Clients access server resources via HTTP requests, which include headers, bodies, and receive responses with data and status codes. These headers provide important context about the request or response. For example, the Content-Type header describes the media type of the resource being sent or received, the Authorization header carries credentials for authenticating the client, and the Accept header lets the server know which media types the client can process. This structure makes RESTful web services flexible, secure, and able to work seamlessly across different platforms and languages.

2. What is a REST Resource?

A REST Resource in the context of RESTful web services (Representational State Transfer) represents an entity or a collection of entities that can be manipulated through a RESTful API. Each resource is identified by a unique URI (Uniform Resource Identifier) and can be accessed and manipulated using standard HTTP methods.

Here are key components of a REST Resource:

1. URI (Uniform Resource Identifier):

   • Each resource is accessible via a unique URI. For example, /users might represent a collection of user resources, while /users/1 might represent a specific user.

2. HTTP Methods:

   1. GET: Retrieve a resource or a collection of resources.

   2. POST: Create a new resource.

   3. PUT: Update an existing resource.

   4. DELETE: Remove a resource.

3. Representation:
   Resources can be represented in various formats, such as JSON, XML, HTML, etc. The client and server negotiate the format through the use of HTTP headers.

4. Stateless Operations:
   Each request from a client to a server must contain all the information the server needs to fulfill the request. The server does not store client context between requests.

5. CRUD Operations:

   • REST resources are often manipulated through CRUD operations (Create, Read, Update, Delete).

   • Example
     Consider a REST API for managing a collection of books in a library:

     • GET /books: Retrieve a list of books.

     • POST /books: Add a new book to the collection.

     • GET /books/{id}: Retrieve details of a specific book by its ID.

     • PUT /books/{id}: Update the details of a specific book by its ID.

     • DELETE /books/{id}: Remove a specific book by its ID.
       
       Each of these endpoints corresponds to a resource (the collection of books or an individual book) and allows for standard HTTP methods to perform operations on those resources.

3. What is URI?

A URI (Uniform Resource Identifier) is a string of characters that identifies a resource on the internet. It provides a way to uniquely identify a resource, such as a web page, a file, or a service.
URIs can take different forms, including URLs (Uniform Resource Locators) and URNs (Uniform Resource Names). URLs specify the location of a resource, while URNs provide a unique name for a resource without specifying its location.

In simpler terms, a URI is like the address of a resource on the internet. Just like a street address helps you find a specific house, a URI helps you locate a specific resource online.

4. What are the features of RESTful Web Services?

Key Features of RESTful Web Services

• Statelessness:
  Each client request contains all the information needed by the server to fulfill that request. The server does not store any client context between requests. This improves scalability and reliability.

• Uniform Interface:
  RESTful services follow a consistent, uniform interface, using standard HTTP methods (GET, POST, PUT, DELETE). This simplifies the interaction between clients and servers and ensures a clear separation of concerns.

• Resource-Based:
  Everything is considered a resource and is identified by a URI (Uniform Resource Identifier). Resources are manipulated using standard HTTP methods, making interactions predictable and consistent.

• Representation-Oriented:
  Resources are represented in various formats (e.g., JSON, XML, HTML). Clients interact with these representations to perform actions on the resources.

• Stateless Operations:
  Each operation (request) is stateless, meaning it does not depend on the previous operations. This allows each request to be treated independently, enhancing reliability and scalability.

• Cacheability:
  Responses from the server are marked as cacheable or non-cacheable, improving efficiency by reducing the need to fetch the same resource multiple times. Caching in REST APIs boosts performance by storing copies of frequently accessed data, minimizing repeated requests to the server. This reduction in redundant data fetching helps decrease both latency and server load. Caching can be applied at multiple levels—on the client, on the server, or via intermediary proxies—and is commonly controlled through HTTP headers such as .

• Layered System:
  RESTful architectures can have multiple layers (e.g., security, load balancing) between the client and the server. Each layer can perform different tasks, improving scalability and manageability.

• Code on Demand (Optional):
  Servers can temporarily extend or customise client functionality by transferring executable code, such as JavaScript. This is optional and used as needed.
  
  

5. What is the concept of statelessness in REST?

In REST, statelessness means that each client request to the server must contain all the information needed to understand and fulfill the request. The server doesn't store any client state between requests, which simplifies scalability and improves reliability. Each request is independent and self-contained, making it easier to manage and scale the system.

A key aspect of this stateless design is that the server does not retain any session information or client context between different requests. This means every HTTP request must include all necessary authentication, parameters, and data for the server to process it. By not holding onto any client-specific state, RESTful systems become inherently more scalable and fault-tolerant, as there's no overhead in tracking or synchronizing sessions. This approach contrasts with stateful APIs, where session information persists and must be maintained across multiple client interactions.

Stateful vs. Stateless APIs

A stateful API retains client state or session information across multiple requests, which means the server is responsible for remembering previous interactions and maintaining session continuity. In contrast, a stateless API—like REST—requires that each request from the client carries all necessary details for the server to process it, without relying on any stored context from previous exchanges. This statelessness improves scalability, as servers can handle more requests without the complexity of managing session data, and also enhances reliability, since any server in a pool can process any request at any time without special coordination.

By adopting a stateless approach, RESTful services make scaling out easier, allow for greater fault tolerance, and reduce potential bottlenecks or failures tied to session management.

6. What do you understand by JAX-RS?

JAX-RS (Java API for RESTful Web Services) is a Java programming language API that provides support for creating RESTful web services. It simplifies the development of RESTful applications in Java by providing annotations and classes for handling HTTP requests and responses. JAX-RS allows developers to build web services that follow REST principles, making it easier to create scalable and interoperable applications.

7. What are HTTP Status codes?

These are the standard codes that refer to the predefined status of the task at the server. Following are the status codes formats available:

1. 1xx - represents informational responses

2. 2xx - represents successful responses

3. 3xx - represents redirects

4. 4xx - represents client errors

5. 5xx - represents server errors

Most commonly used status codes are:

1. 200 - success/OK

2. 201 - CREATED - used in POST or PUT methods.

3. 304 - NOT MODIFIED - used in conditional GET requests to reduce the bandwidth use of the network. Here, the body of the response sent should be empty.

4. 400 - BAD REQUEST - This can be due to validation errors or missing input data.

5. 401- UNAUTHORISED - This is returned when there is no valid authentication credentials sent along with the request.

6. 403 - FORBIDDEN - sent when the user does not have access (or is forbidden) to the resource.

7. 404 - NOT FOUND - Resource method is not available.

8. 500 - INTERNAL SERVER ERROR - server threw some exceptions while running the method.

9. 502 - BAD GATEWAY - Server was not able to get the response from another upstream server
   
   

8. What are the HTTP Methods?

The HTTP methods, also known as HTTP verbs, are actions that clients can perform on resources located on a server.

They indicate the desired action to be performed on the specified resource. Here are the common HTTP methods:

• GET: Retrieves data from the server. It should only retrieve data and should not have any other effect on the server.

• POST: Submits data to the server to create a new resource. It often results in a change in state or side effects on the server.

• PUT: Updates an existing resource on the server with the provided data. It replaces the entire resource with the new data. With PUT, you are expected to send a complete representation of the resource; any missing fields may be set to their default or removed, as PUT will overwrite the entire resource.

• PATCH: Partially updates an existing resource on the server with the provided data. It only updates the specified fields without replacing the entire resource. Unlike PUT, PATCH is more efficient when you only want to modify a few attributes because it leaves the rest of the resource unchanged.

• DELETE: Removes the specified resource from the server.

• HEAD: Retrieves the headers for a resource without the body content. It is often used to check the status of a resource or to retrieve metadata.

• OPTIONS: Returns the HTTP methods that the server supports for a specified URL. It is often used for cross-origin resource sharing (CORS) requests.

  PUT vs PATCH in Practice

  To clarify, while both PUT and PATCH are used to update resources, their behavior differs:

  • PUT: Replaces the entire resource with the representation you provide. If you omit any fields, those fields may be removed or set to default values.

  • PATCH: Applies only the updates you specify, leaving all other fields untouched. This makes PATCH ideal for partial updates without affecting the rest of the resource.

    
    These HTTP methods allow clients to interact with resources on the server in various ways, enabling a wide range of functionalities in web applications.

9. Advantage and disadvantages of RESTful web services?
   
   

• Advantages of RESTful Web Services:

  • Simplicity: Easy to understand and implement with standard HTTP methods.

  • Scalability: Stateless communication and caching support efficient scaling.

  • Interoperability: Can be accessed from any platform using standard web protocols.

  • Flexibility: Support for various data formats, providing flexibility in data representation.

  • Performance: Lightweight communication and caching mechanisms improve performance.

    
    

• Disadvantages of RESTful Web Services:

  • Lack of Standardisation: Variations in implementation may lead to inconsistency.

  • Security Concerns: Reliance on standard web security mechanisms may not suffice for all needs.

  • Overhead: Additional HTTP communication may introduce overhead, affecting performance.

  • Limited Support for Complex Transactions: Not ideal for complex transactions requiring multi-step processes.

  • Dependency on Network: Susceptible to network latency, failures, and availability issues.

Rate limiting is a technique used to control how many requests a client can make to a REST API within a specified period of time. By setting these limits, APIs can prevent excessive or abusive traffic from overloading the system, which helps to maintain consistent performance and availability for all users.

For example, a public API like GitHub's might allow only 60 requests per hour for unauthenticated clients, ensuring that no single user consumes all the server resources. Rate limiting also protects against denial-of-service attacks and helps enforce fair usage policies. Typically, when a client exceeds the allowed limit, the server will respond with a specific status code, such as 429 Too Many Requests, prompting the client to slow down or try again later.

10. Can you explain the concept of HATEOAS in REST?

HATEOAS (Hypermedia As The Engine Of Application State) is a constraint of the REST application architecture. It means that the client interacts with the application entirely through hypermedia provided dynamically by application servers. In other words, the server provides links to related resources, allowing clients to navigate the API dynamically.

11. What is the concept of idempotency in REST APIs and how is it implemented?

Idempotency in REST APIs refers to the property where making the same request multiple times produces the same effect as making it once. In practical terms, this means that no matter how many times you send an identical request, the state of the resource on the server remains consistent and unchanged beyond the initial application.

For example:

• GET: Fetching the details of a book with GET /books/{id} will always return the same information about the book, without modifying any data.

• PUT: Updating a book with PUT /books/{id} using the same data every time will always result in the book having that data—whether you send the request once, twice, or more.

• DELETE: Removing a book with DELETE /books/{id} means the book is deleted after the first request, and further delete requests will have no additional effect (the book remains gone).

Idempotency is important because it helps prevent unintended changes or errors if a network hiccup causes a client to repeat a request. In REST, methods like GET, PUT, and DELETE are designed to be idempotent, ensuring predictable and reliable behavior for clients and servers alike.

12. What are the key differences between REST and SOAP?

REST and SOAP are two prominent ways to enable communication between web services, but they differ in some fundamental ways.

• REST (Representational State Transfer) is an architectural style that leverages standard HTTP methods like GET, POST, PUT, and DELETE. It's known for its simplicity and lightweight approach, allowing for data exchange in formats like JSON, XML, or even plain text. REST is often chosen for its flexibility and ease of integration across different platforms.

• SOAP (Simple Object Access Protocol), meanwhile, is a protocol with established standards and a strict message structure. It relies exclusively on XML for message format and requires more overhead. SOAP is often used in enterprise environments where robust security, transactional reliability, and formal contracts (WSDL) are crucial.

In summary, REST offers flexibility and ease of use, while SOAP emphasizes standardization and robust features, making the choice dependent on specific requirements and project needs.

13. How do REST APIs handle versioning, and why is it important?

Versioning in REST APIs plays a crucial role in maintaining stability as APIs evolve over time. Since clients often integrate deeply with specific API structures, sudden changes can break functionality or require unexpected updates. By introducing versioning, API providers ensure that older clients can continue interacting with the API as originally designed, even as newer features or major changes are rolled out for other users.

There are several common ways to implement versioning in REST APIs:

• URI Versioning:
  The version is included directly in the URI path, such as /v1/users or /api/v2/products. This is easily visible and straightforward to manage but can sometimes lead to duplicated endpoints as versions increase.

• Request Header Versioning:
  The client specifies the API version in a custom request header (for example, API-Version: 2). This keeps versions out of the URI and can help with more granular version management.

• Media Type Versioning (a.k.a. Content Negotiation):
  Here, the version is included in the Accept header, such as Accept: application/vnd.company.v2+json. This approach is often used when different media types or representations are supported.

The choice depends on the needs of the API and the preferences of its consumers. Whichever method is used, the primary goal is to provide a seamless experience for clients, allowing upgrades at their own pace while minimizing disruptions. This careful approach to versioning contributes to robust, long-lasting API integrations that don’t catch users off guard with breaking changes.

14. What is OAuth, and how is it used in the context of REST APIs?

OAuth is an industry-standard protocol for authorization that allows users to grant third-party applications limited access to their resources without sharing their actual credentials. In the context of REST APIs, OAuth enables secure access by issuing access tokens after a successful authentication process (such as logging in with Google or GitHub). These tokens are then included in API requests, allowing applications to perform actions on behalf of the user—while keeping passwords and sensitive details safe.

This means, for example, a scheduling app can read your Google Calendar events without ever directly knowing your Google password. OAuth is widely adopted for enabling secure, delegated access in modern REST API integrations.

Let's explore how you can establish a comprehensive test infrastructure with Qodex.ai.

With Qodex.ai, you have an AI co-pilot Software Test Engineer at your service. Our autonomous AI Agent assists software development teams in conducting end-to-end testing for both frontend and backend services. This support enables teams to accelerate their release cycles by up to 2 times while reducing their QA budget by one-third.