REST API Interview Questions

Here is a list of top 15 REST API interview questions and answers.  These questions would provide you with basic information about both simple and advanced topics.

What is a Web API?

A Web API (Application Programming Interface) is a set of protocols and tools that allows different software applications to communicate with each other. Web APIs enable developers to create applications that can interact with other applications or services over the internet using standard protocols like HTTP, REST, and JSON.

What is REST API ?

REpresentational State Transfer, or REST for short, is an architectural style for building distributed, client-server systems. By providing a small set of useful guidelines and constraints REST makes it easy to build large-scale systems that are loosely coupled, distributed over large internet-scale networks that can be efficient & maintainable while evolving over time.

Which protocol is used by RESTful web services?

A REST API or a RESTFul webservice is a webservice implemented using the REST architectural guidelines, usually on top of HTTP. Unlike the normal HTML content served over HTTP, though, the REST API are designed to be consumed by other pieces of software, referred to as REST Clients. The HTTP verbs and request/ response data structures are leveraged for messaging and communication between the REST API Provider and the REST Client. The term RESTFul webservice is also used to distinguish from the other popular type of webservice, i.e., the SOAP web-service.

What are the main HTTP methods used in RESTful APIs?

The main HTTP methods used in RESTful APIs are:

• GET: Retrieve a resource or a collection of resources.
• POST: Create a new resource.
• PUT: Update an existing resource.
• DELETE: Delete a resource.
• PATCH: Partially update a resource.

What is the difference between PUT and PATCH?

The difference between PUT and PATCH lies in how they update a resource:

• PUT: Replaces the entire resource with the new data provided in the request. If some fields are not included in the request, they will be removed or set to their default values.
• PATCH: Applies partial updates to the resource, only modifying the fields specified in the request.

What is JSON?

JSON (JavaScript Object Notation) is a lightweight data-interchange format that is easy to read and write for humans and easy to parse and generate for machines. JSON is widely used for data serialization in Web APIs due to its simplicity and compatibility with various programming languages.

What is an API endpoint?

An API endpoint is a specific address (URL) where an API exposes its resources and services to clients. The endpoint represents the entry point for a particular API function or operation, such as retrieving data, creating new records, or updating existing ones.

What is authentication and authorization in the context of Web APIs?

Authentication is the process of verifying the identity of a user or system trying to access a Web API. Authorization, on the other hand, determines what actions and resources the authenticated user or system is allowed to access.

What are some common authentication mechanisms used in Web APIs?

Some common authentication mechanisms used in Web APIs include:

• Basic Authentication: Requires the client to provide a username and password, which are sent as base64-encoded text in the HTTP header.
• API Key: Requires the client to provide a unique key in the request header or as a query parameter.
• OAuth: A more advanced and secure authentication framework that allows users to grant third-party applications limited access to their resources without sharing their credentials.

What is CORS?

CORS (Cross-Origin Resource Sharing) is a security feature implemented by web browsers that restricts web pages from making requests to a different domain than the one that served the web page. CORS enables servers to specify which domains are allowed to access their resources and under what conditions, preventing unauthorized access to API resources from different origins.

What is API versioning, and why is it important?

API versioning is the practice of maintaining multiple versions of an API to ensure backward compatibility and avoid breaking changes for existing clients. As APIs evolve and new features are added or existing ones are modified, versioning allows developers to make these changes without affecting clients that rely on older versions of the API.

How do you address a resource in RESTful web service?

A REST API, essentially, is about exposing Resources. Every end-point in a REST API is a reference to some resource on the server. This resource is identified by the URI (Uniform Resource Identifier).

How is resource represented in a REST API ?

When a REST API request is received by the server, it responds with a representation of the resource. This is usually in XML or JSON format altough other formats are allowed. API endpoints can also specify a list of supported formats from which the client can choose the desired format.

The client can then use this to discover other functionality provided by the API or request other resources – thus using the representation to transfer state.

What are the core components of a HTTP request?

The HTTP verb used to access the resource (GET, PUT, POST, DELETE etc.,.) signifies the action requested. For example, an HTTP GET request on the EmployeeData endpoint would read and return a representation of the EmployeeData while a PUT request may be used to make changes to it.

What are some common API versioning strategies?

Some common API versioning strategies include:

• URI versioning: Include the version number in the API endpoint’s URL (e.g., /api/v1/users).
• Header versioning: Include the version number in a custom HTTP header (e.g., X-API-Version: 1).
• Query parameter versioning: Include the version number as a query parameter in the URL (e.g., /api/users?version=1).

What is API throttling?

API throttling is the practice of limiting the number of requests a client can make to an API within a specified time frame. This is usually done to prevent excessive use of resources, protect against abuse or denial-of-service attacks, and ensure fair usage among all clients.

What is an API Gateway?

An API Gateway is a server that acts as an entry point for clients to access various microservices or APIs within an application. It can handle tasks such as load balancing, authentication, authorization, API versioning, and request/response transformation.

What is HATEOAS, and how is it used in RESTful APIs?

HATEOAS (Hypermedia as the Engine of Application State) is a constraint in REST architecture that allows clients to discover available actions and resources by navigating hypermedia links returned in the API response. By including links to related resources and actions in the API response, clients can dynamically interact with the API without prior knowledge of its structure.

What is Swagger, and how does it help with Web API development?

Swagger, now known as OpenAPI, is a specification for describing, documenting, and testing RESTful APIs. It provides a standard format for defining API endpoints, request/response structures, authentication mechanisms, and other metadata. Tools like Swagger UI and Swagger Editor can generate interactive documentation and client SDKs based on the Swagger specification, making it easier for developers to understand and consume the API.

What is the difference between SOAP and REST?

SOAP (Simple Object Access Protocol) and REST (Representational State Transfer) are two different approaches to building web services. The main differences between them are:

• SOAP is a protocol based on XML, while REST is an architectural style that can use various data formats, including XML, JSON, and plain text.
• SOAP relies on predefined operations and strict contracts (WSDL), whereas RESTful APIs use standard HTTP methods and are more flexible in terms of resource representations.
• REST is generally considered easier to work with, more scalable, and better suited for web applications due to its simplicity and stateless nature.

How can you handle errors in a RESTful API?

In a RESTful API, errors should be communicated to clients using appropriate HTTP status codes (e.g., 400 Bad Request, 404 Not Found, 500 Internal Server Error) and, optionally, a descriptive error message or an error object in the response body. This allows clients to understand the cause of the error and take appropriate action if necessary.

What is CORS, and why is it important for Web APIs?

CORS (Cross-Origin Resource Sharing) is a security mechanism implemented by web browsers that allows web applications to make requests to APIs hosted on different domains. By default, browsers block cross-origin requests to protect against cross-site request forgery (CSRF) attacks. CORS enables web APIs to explicitly allow cross-origin requests from specific domains, making it possible for web applications to interact with APIs hosted on different servers.

What is OAuth, and how is it used for API authentication?

OAuth (Open Authorization) is an open standard for token-based authentication and authorization, commonly used to secure access to web APIs. It allows third-party applications to obtain limited access to an API on behalf of a user without requiring the user’s credentials. Instead, OAuth uses access tokens that are granted by an authorization server after the user has authenticated and authorized the application. These tokens can be used by the application to access the API on the user’s behalf.

What is the difference between authentication and authorization in the context of Web APIs?

Authentication is the process of verifying the identity of a user or client, while authorization is the process of determining what actions or resources the authenticated user or client is allowed to access. In the context of Web APIs, authentication is typically achieved using methods like API keys, tokens, or OAuth, while authorization can be managed through access control mechanisms like role-based access control (RBAC) or attribute-based access control (ABAC).

What are idempotent HTTP methods, and why are they important for Web APIs?

Idempotent HTTP methods are those that can be called multiple times with the same parameters without causing any side effects or changing the state of the system. Examples of idempotent methods include GET, HEAD, PUT, and DELETE. Non-idempotent methods, such as POST and PATCH, can cause side effects or change the state of the system when called multiple times. Using idempotent methods for Web APIs is important because it helps ensure that clients can safely retry requests in case of network failures or timeouts without causing unintended consequences.

What is API versioning, and why is it important?

API versioning is the process of introducing changes to an API while maintaining backward compatibility with existing clients. This can be achieved by creating different versions of the API, each with its own set of endpoints, request/response structures, and functionality. API versioning is important because it allows developers to evolve and improve their APIs over time without breaking existing integrations or forcing clients to upgrade immediately. Common approaches to API versioning include using URI versioning, query parameter versioning, and custom request headers.

What is the difference between REST API and the traditional API?

Thus the REST API deals with resources (nouns) rather than actions (verbs), which is a crucial difference. For example, while a traditional API may have an interface named “GetEmployeeData”, in a REST API, this is achieved by requesting the EmployeeData endpoint (presumably using an EmployeeId).

Can there be more than one URI for the same resource?

The same resource can have more than one URI. For example http://example.com/employee/eid/department and http://example.com/departments?name=”finance” could both refer to the same resource.

What are the advantages of a REST API?

The REST architectural style makes it easy and efficient to build scalable web-services and applications. Some of its advantages are:

• Uniform interface: Interface between client and server is defined. Due to this, the architecture of client and server is completely decoupled.
• It also simplifies the client as well as the server design since every end-point of the API implements (a subset of) the same set of methods. These methods are the HTTP verbs (GET, PUT, POST, DELETE, HEAD and OPTIONS).
• REST allows the client and server side to evolve independently. Because the API is made up of resources exposed via end-points, the client can discover any new resources available and start making use of them. REST also allows code to be sent as a response allowing the server to extend the client.
• Due to its growing popularity and adoption, there is a lot of ecosystem support to bootstrap new services easily. Support for creating and consuming RESTFul web-services is available on almost all major technologies and platforms.
• Of course, by its very nature of being based on HTTP, REST is platform agnostic and thus, RESTFul web-services developed using disparate technology stacks can easily interoperate. This is really important for smooth enterprise integration & avoiding lock-in.
• In a REST API, no state is stored on the server. Every request has all the information necessary for the server to respond. Thus, any session state is stored in the client. This makes it easy for the backend to scale.
• In a REST API there is separation of concerns between the client and the server. The presentation and user-interaction is handled by the client while the server deals with data storage and retrieval.
• Cacheable responses and the notion of a layered system between the client and server make a system build on REST API more robust in dealing with network delays and fluctuations in network traffic.

Where is REST API popular?

Due to above advantages it is little wonder that REST has gained widespread adoption and use. Top technology companies and social media giants like Facebook, Google and Twitter provide REST API endpoints to their services for programmatic use of their services apart from using them heavily within their own software stack.

List the points to be remembered while designing a REST API.

Below are the key points to be remembered while designing a REST API.

1. In a REST API everything is a resource. Every API request returns a response that is a representation of the resource.
2. Representations are not the same as the resource. This maybe obvious at some level but is an important distinction to make.
3. Resource representations are typically in XML or JSON format. Client can request the format specifically by setting appropriate request headers.
4. No state is stored on the server. Session state is stored entirely on the client. Every request to the server contains all the necessary information the server needs to process it without depending on any context stored on the server.
5. Cacheable responses. Client cannot assume direct connection to server – there may be intermediaries (which may, for example, cache the response). The system is layered (E.g., a response to a REST API may require the server to invoke another REST API whose response maybe cached by the server) and there could be several layers between the client and the server. This improves scalability of the system (e.g., ability to add a load-balancer).

What are the HTTP Verbs and their common meanings?

Of the 6 HTTP verbs, GET, POST, PUT and DELETE are more commonly used. The primary usage of these verbs are summarized below.

GET – Read resource/ collection of resources. This verb is used to get a representation of a resource or a collection of resources by using an identifier.

PUT – Update or Create a new resource. Usually this is used to update an existing resource and the information to be updated is passed in with the request. In case the identifier is known before-hand then this method can also be used to create a new resource corresponding to the identifier.

POST – Create a new resource. The information necessary to create the resource is passed in with the request. Upon success, the response usually contains the identifier of the resource created. This method is also used for operations that do not fit into any other category.

DELETE – Remove a resource.

HEAD – Returns only the HTTP header and no BODY.

OPTIONS – Return the list of operations supported on this resource.

What is the difference between PUT and POST?

Invoking, “PUT” puts a resource at the URI. If it already exists, PUT changes it. If it doesn’t, then PUT makes one.

On the other hand, POST is used to send data to a URI. The provider of the API can decide what to do with the data (create a resource, store it somewhere, …) in the context of the request and the resource at which the request is made.

PUT is idempotent, i.e., invoking it multiple times will not have any impact (it will put the same resource or make the same change to it). POST is not idempotent. Thus, if invoked multiple times POST will repeat the same operation (creating more resources or storing copies of the data etc).

In REST API, what is separation of concerns between the client and server ?

The presentation and user-interaction is handled by the client while the server deals with data storage and retrieval. This is known as separation of concerns – this helps the client and server focus on doing their respective roles well.

List key differences between SOAP and REST

SOAP is a protocol and SOAP web-services communicate purely by exchanging XML. REST is an architectural style that is built on top of HTTP and REST API can exchange data in multiple formats (including XML and JSON).

A SOAP service has a custom interface defined via WSDL. A REST API has a uniform interface based on HTTP verbs. While SOAP uses HTTP protocol to embed an XML message (which is the API object), REST uses HTTP headers to carry meta information for the request and response.

SOAP vs REST is probably the most common question asked in interviews. It is very important to know when to use any one of them. The most important point to understand is the contract between client and server.  For SOAP, if anything changes on server, the client has to adopt.  So Client needs to know all the services it will be using before starting any interaction with the server.

For REST Services, the clients can handle the services changes more gracefully.  REST clients have been very easy to write. If a SOAP client is written in JavaScript, it would need a ton of code to make a simple interaction with service. But for REST services, it can be done with few lines of code. That has made rest a preferred way of communication between browsers and servers via JavaScript.

One important thing to remember is that SOAP and REST is that it is not actually SOAP vs REST. There are environments where SOAP services make more sense. Like we use SOAP service between two different applications communicating to each other. And we use REST services for our GUI related services. And REST and SOAP can be used also together. Like GUI calling a rest service which internally interacts with a SOAP services. So the complexity of SOAP service is not exposed to web clients.

Remember it is not SOAP vs REST but a good answer would be depends when to use which of them.

Explain how caching in a REST API takes advantage of the layered nature of the internet ?

While creating the response to an API request, the server sets the “cache-control” HTTP header to indicate the cacheability. When cache-control header has the Public directive set the response is cacheable by any component (this means, the same request originating from another REST Client and passing through the same intermediary will receive the cached response, thus saving a call to the server). When it has the Private directive then only the client may cache it (not the intermediaries).

On top of this other HTTP headers like “expires”, “max-age”, “must-revalidate” further provide details about how long the response may be cached and what needs to be done when it is past the expiration time. For more on the semantics of the HTTP cache-control headers see this article.

What is the meaning of popular HTTP Status Codes ?

200 – OK (Success)
201 – CREATED (Usually for PUT or POST when resource is created successfully)
204 – NO CONTENT (Empty body)
400 – BAD REQUEST
401 – FORBIDDEN (Access denied to method requested)
404 – NOT FOUND (resource or method not found)
500 – INTERNAL SERVER ERROR (Generic code returned when server encountered an exception while processing the request)

Enumerate some popular JAX-RS implementations that can be used for developing RESTFul web-services in Java

Jersey
Apache CXF
Restlet
JBoss RESTEasy

Additional Resources

Head here for a detailed introduction to REST.

Looking for step-by-step instructions ? Read these articles to find out more about creating REST-ful web-services in Java with Jersey, spring, spring-mvc, spring-boot and a REST client. Or, move on to advanced topics such a securing a REST service with authentication.