27 REST API Interview Questions (ANSWERED) Devs Must Know

REST is the acronym for REpresentational State Transfer. REST is an architectural style for developing applications that can be accessed over the network. REST architectural style was brought in light by Roy Fielding in his doctoral thesis in 2000.

REST is a stateless client-server architecture where web services are resources and can be identified by their URIs. Client applications can use HTTP GET/POST methods to invoke Restful web services. REST doesn’t specify any specific protocol to use, but in almost all cases it’s used over HTTP/HTTPS.

When compared to SOAP web services, these are lightweight and doesn’t follow any standard. We can use XML, JSON, text or any other type of data for request and response.

Some key characteristics of REST includes

• REST is stateless, therefore the SERVER has no state (or session data)
• With a well-applied REST API, the server could be restarted between two calls as every data is passed to the server
• Web service mostly uses POST method to make operations, whereas REST uses GET to access resources

Ajax

• In Ajax, the request are sent to the server by using XMLHttpRequest objects. The response is used by the JavaScript code to dynamically alter the current page
• Ajax is a set of technology; it is a technique of dynamically updating parts of UI without having to reload the page
• Ajax eliminates the interaction between the customer and server asynchronously

REST

• REST requires the interaction between the customer and server
• REST have a URL structure and a request/response pattern the revolve around the use of resources
• REST is a type of software architecture and a method for users to request data or information from servers
• REST requires the interaction between the customer and server

Some of the advantages of REST web services are:

• Learning curve is easy since it works on HTTP protocol
• Supports multiple technologies for data transfer such as text, xml, json, image etc.
• No contract defined between server and client, so loosely coupled implementation.
• REST is a lightweight protocol
• REST methods can be tested easily over browser.

Resource is the fundamental concept of Restful architecture. A resource is an object with:

• a type,
• relationship with other resources and
• methods that operate on it.

Resources are identified with:

• their URI,
• HTTP methods they support and
• request/response data type and format of data.

URI stands for Uniform Resource Identifier. Each resource in REST architecture is identified by its URI. Purpose of an URI is to locate a resource(s) on the server hosting the web service.

A URI is of following format:

<protocol>://<service-name>/<ResourceType>/<ResourceID>

• Clients – Different users from various devices send requests.
• Identity Providers – Authenticates user or clients identities and issues security tokens.
• API Gateway – Handles client requests.
• Static Content – Houses all the content of the system.
• Management –  Balances services on nodes and identifies failures.
• Service Discovery – A guide to find the route of communication between microservices.
• Content Delivery Networks – Distributed network of proxy servers and their data centers.
• Remote Service – Enables the remote access information that resides on a network of IT devices.

HTTP methods supported by REST are:

• GET: It requests a resource at the request URL. It should not contain a request body as it will be discarded. Maybe it can be cached locally or on the server.
• POST: It submits information to the service for processing; it should typically return the modified or new resource
• PUT: At the request URL it update the resource
• DELETE: At the request URL it removes the resource
• OPTIONS: It indicates which techniques are supported
• HEAD: About the request URL it returns meta information

PUT puts a file or resource at a particular URI and exactly at that URI. If there is already a file or resource at that URI, PUT changes that file or resource. If there is no resource or file there, PUT makes one

POST sends data to a particular URI and expects the resource at that URI to deal with the request. The web server at this point can decide what to do with the data in the context of specified resource

PUT is idempotent meaning, invoking it any number of times will not have an impact on resources.

However, POST is not idempotent, meaning if you invoke POST multiple times it keeps creating more resources

Some of the disadvantages of REST are:

• Since there is no contract defined between service and client, it has to be communicated through other means such as documentation or emails.
• Since it works on HTTP, there can’t be asynchronous calls.
• Sessions can’t be maintained.

Following are important points to be considered while designing a URI:

• Use Plural Noun − Use plural noun to define resources. For example, we've used users to identify users as a resource.

• Avoid using spaces − Use underscore(_) or hyphen(-) when using a long resource name, for example, use authorized_users instead of authorized%20users.

• Use lowercase letters − Although URI is case-insensitive, it is good practice to keep url in lower case letters only.

• Maintain Backward Compatibility − As Web Service is a public service, a URI once made public should always be available. In case, URI gets updated, redirect the older URI to new URI using HTTP Status code, 300.

• Use HTTP Verb − Always use HTTP Verb like GET, PUT, and DELETE to do the operations on the resource. It is not good to use operations names in URI.

Following are important points to be considered while designing a representation format of a resource in a RESTful web services −

• Understandability − Both Server and Client should be able to understand and utilize the representation format of the resource.

• Completeness − Format should be able to represent a resource completely. For example, a resource can contain another resource. Format should be able to represent simple as well as complex structures of resources.

• Linkablity − A resource can have a linkage to another resource, a format should be able to handles such situations.

Following is the disadvantage of statelessness in RESTful web services:

• Web services need to get extra information in each request and then interpret to get the client's state in case client interactions are to be taken care of.

To ensure reliable transactions and secure confidential information, web services requires very high level of security which can be only achieved through Entrust Secure Transaction Platform. Security issues for web services are broadly divided into three sections as described below

1) Confidentiality: A single web service can have multiple applications and their service path contains a potential weak link at its nodes. Whenever messages or say XML requests are sent by the client along with the service path to the server, they must be encrypted. Thus, maintaining the confidentiality of the communication is a must.

2) Authentication: Authentication is basically performed to verify the identity of the users as well as ensuring that the user using the web service has the right to use or not? Authentication is also done to track user’s activity. There are several options that can be considered for this purpose

• Application level authentication
• HTTP digest and HTTP basic authentication
• Client certificates

3) Network Security: This is a serious issue which requires tools to filter web service traffic.

Addressing refers to locating a resource or multiple resources lying on the server. It is analogous to locate a postal address of a person.

As per REST architecture, a RESTful web service should not keep a client state on server. This restriction is called statelessness. It is responsibility of the client to pass its context to server and then server can store this context to process client's further request. For example, session maintained by server is identified by session identifier passed by the client.

• Monolithic Architecture is similar to a big container wherein all the software components of an application are assembled together and tightly packaged.
• A Service-Oriented Architecture is a collection of services which communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity.
• Microservice Architecture is an architectural style that structures an application as a collection of small autonomous services, modeled around a business domain.

HTTP Status code are standard codes and refers to predefined status of task done at server. For example, HTTP Status 404 states that requested resource is not present on server.

Consider following status codes:

• 200 - OK, shows success.
• 201 - CREATED, when a resource is successful created using POST or PUT request. Return link to newly created resource using location header.
• 304 - NOT MODIFIED, used to reduce network bandwidth usage in case of conditional GET requests. Response body should be empty. Headers should have date, location etc.
• 400 - BAD REQUEST, states that invalid input is provided e.g. validation error, missing data.
• 401 - FORBIDDEN, states that user is not having access to method being used for example, delete access without admin rights.
• 404 - NOT FOUND, states that method is not available.
• 409 - CONFLICT, states conflict situation while executing the method for example, adding duplicate entry.
• 500 - INTERNAL SERVER ERROR, states that server has thrown some exception while executing the method.

• Accept headers tells web service what kind of response client is accepting, so if a web service is capable of sending response in XML and JSON format and client sends Accept header as application/xml then XML response will be sent. For Accept header application/json, server will send the JSON response.

• Content-Type header is used to tell server what is the format of data being sent in the request. If Content-Type header is application/xml then server will try to parse it as XML data. This header is useful in HTTP Post and Put requests.

GraphQL and microservices are a perfect fit, because GraphQL hides the fact that you have a microservice architecture from the clients. From a backend perspective, you want to split everything into microservices, but from a frontend perspective, you would like all your data to come from a single API. Using GraphQL is the best way I know of that lets you do both. It lets you split up your backend into microservices, while still providing a single API to all your application, and allowing joins across data from different services.