Answers To The Most Common REST API Interview Questions

REST APIs are one of the most prominent software architectures among web services. Having a strong understanding of this architecture and its applications is critical to Backend, Full-Stack, and other Software Developer roles.

This article will take you through some common REST API Interview Questions and detail what you need to understand to appropriately answer each question.

What is REST?

REST, standing for Representational State Transfer, is an architecture that debuted in 2000 based on the idea of a client and server communicating through Requests and Responses without the need for stateful data. A web service or API following the REST architecture is considered to be RESTful.

Before REST, SOAP was used to implement APIs using XML documents and a Remote Procedure Call.

In 2000, Roy Fielding created the universal rules for REST, making the rules general so that any Software could be applied upon that Standard.

In 2002, Both Amazon and eBay would adopt use of REST APIs as it allowed scale on the e-commerce platform

By 2006, large-scale adoption of REST APIs had occurred.

REST APIs are based on the idea of back-and-forth communication using Requests and Responses between two endpoints, typically a Client and Server, while both endpoints refrain from keeping any data on the other.

In short, the REST architecture allows for the transfer of content, called resources, from the server to the client by means of an HTTP method and a URI.

How are REST APIs Stateless?

To answer this question, first understand the meaning of Stateful and Stateless.

An application, API, or web service that is considered Stateful stores some data from the client on its own servers.

For example, if a username and password were passed from the client to the server as a form of authentication and the server stores that data then the web server is Stateful

This is because the server is now storing data from the client.

By contrast, the REST architecture requires that the client's state is not stored on the server. Instead, each request made by the client must contain all necessary information for that particular HTTP method.

Explain the HTTP Methods

RESTful web-services will utilize HTTP Methods in client Requests. The below shows some of the most common HTTP methods.

• GET: Fetches a resource from the Server. May fetch one resource using a URI with an id or many resources using a URI without an id
• POST: Requests for a resource to be created on the Server. Client will send the necessary information for said resource to be created. Server should return the created resource.
• PUT: Requests for a resource to be updated. Done by providing a new version of the resource. If the specified resource does not exist, it will be created.
• PATCH: Requests for a resource to be updated, but instead of replacing the entire resource, PATCH updates only parts of a given resource. It is typically used an alternative to PUT. If the specified resource does not exist, an error will occur rather than the resource being created.
• DELETE: Requests for a resource to be deleted. Like GET, DELETE can be applied to one or many resources.
• OPTIONS: Server returns a list of all supported HTTP operations at the URI
• HEAD: Server returns URI's meta information.

Of the above, GET, POST, PUT, and DELETE, are the most commonly found among RESTful web-services because these four correspond to CRUD operations i.e. Create, Read, Update, Delete.

Explain the HTTP Status Codes

RESTful web-services will utilize HTTP Status Codes in server Responses.

There are 5 categories of HTTP status codes with several codes in each category.

The below shows each category along with a  few common codes in each category.

(Format) 1xx - represents an informational response i.e. the server is providing information to the client.

(Format) 2xx - represents a successful Request and Response.

• 200 - Request was successful. A generic but common status code.
• 201 - Resource creation was successful. Typically used in response to a POST request

(Format) 3xx - represents a redirect. This means further action is needed from the client to carry out the request.

(Format) 4xx - represents a client-side error

• 400 - Bad Client Request. A generic status code meaning there was some issue with the Client's request. The server was not at fault.
• 401 - User does not have necessary authorization.
• 404 - Resource not found or method not available. Used commonly when a URI does not contain a resource required for a GET, DELETE, or PUT method.

(Format) 5xx - represents a server-side error

• 500 - Server error. A generic status code meaning the Server raised some error while processing the Request from the client. The client was not at fault.
• 502 - Server could not get response from another server. This means that internally, the server made its own request to another server which, for whatever reason, did not respond.

Of the above, 2xx, 4xx, and 5xx status codes are the most common types of HTTP status codes.

What is a URI?

A URI stands for Uniform Resource Identifier. It identifies every resource in the REST architecture. A URI can be one of two types:

• URN: Identifies a resource through a unique and persistent name. This can include identifiers such as ISBN and ISSN numbers.
• URL: Also called a web address. Take the following example:

An example of a URI:

https://www.tryexponent.com/courses/software-engineering/

It has a protocol (https://), a domain (www.tryexponent.com), and a path (/courses/software-engineering) and potentially an id: a set of numbers that identifies a specific resource.

In this way, URLs both identify a resource and indicate where the resource may be found.

Also note that this process of locating a resource through a URI or URL is called addressing.

Typically on the web, URLs will be used when designing REST APIs and the terms URL and URI are used interchangeably.

What are some best practices in making the URI for a RESTful web-service?

URIs should be kept mostly standardized when developing a RESTful web-service. This way, clients can more easily work with the web-service. The following is a list of best practices when making RESTful URIs

1. Develop with the understanding that forward slashes indicate hierarchy

Within a URI, forward slashes indicate hierarchy in much the same way as a file structure or tree.

Examples:

1. tryexponent.com/users/{id} this indicates that the id is the id of a user
2. tryexponent.com/courses/software-engineering this URI indicates there is a collection of courses in the category of software-enginnering.
3. This may be taken further with the understanding that an id may itself have its own collections, such as: tryexponent.com/users/{id}/accounts

Use plural nouns for branches

In a URI, there are collections and singletons i.e. many resources and a single resource. The URI can reflect this by using plural nouns for any branches to represent collections.

A singleton can be identified with an id within that collection

Examples:

tryexponent.com/users/{id} Better

tryexponent.com/user/{id} Worse

The word "users" accurately represents the plural property of the many users, while an id may be used beneath this to reflect one of those users

Use hyphens for multiple words

In a URI, hyphens are the best options for stringing together multiple words. Spaces will typically cause errors, and underscores may appear as spaces.

Use lower case

URIs are not case sensitive, but it is a best-practice that the URI be composed of lower-case letters only.

Maintain backwards compatibility, use 300 status codes as necessary

If a URI is deprecated in the update to an API, ensure that you use the 300 status code to redirect the client to whichever updated URI is needed

Don't use http methods in a URI

HTTP Methods or verbs should not be used in place of nouns within a URI as this can cause confusion.

Examples:

tryexponent.com/getUser tryexponent.com/users

Suppose the API needed to delete a user. This would be confusing if it had to be done through the branch "getUser", but creating multiple branches for each method is terribly inefficient.

Therefore, use Nouns, not verbs.

Refrain from using file extensions

It is generally a best practice to keep file extensions out of a URI as they add no value and only complicate the existing URI.

Examples:

tryexponent.com/example.json tryexponent.com/example

REST vs SOAP?

While REST is an architecture used to develop web-services, SOAP, Simple Object Access Protocol, serves as a protocol for exchanging structured information by way of APIs.

While REST sets flexible standards, SOAP standards are much stricter in their implementation, and its statefulness often means that the Client and Server are much closer connected.

Additionally, while REST allows for data transfer in JSON, XML, and others, SOAP only supports XML.

In general, SOAP is a stricter and more niche alternative to REST, used in cases where more regulated and stateful data needs to be transferred.

What are the differences between REST and AJAX?

AJAX refers to Asynchronous Javascript and XML. It's a collection of web technologies that allow for asynchronous web applications using the built-in XMLHttpRequest Object.

While REST API refers to a software architecture for handling HTTP Requests, AJAX refers to a collection of web technologies for making asynchronous web Requests: two fundamentally different concepts.

This means that a REST API may handle AJAX Clients, and that AJAX may be used to send RESTful Requests, but a REST API could not be implemented nor replaced via AJAX.

What are some tools used to develop and test REST APIs?

The tools used to develop REST APIs depend on the language used to develop the API. Different tools exist depending on whether the language is Java, Node.JS, Python etc.

In the case of Node.JS, frameworks such as Express are commonly used, though there are countless options including Nest and Fastify.

With Java, some of the most used development tools for making REST APIs are Spring, and Jersey API.

In the world of Python, there are several tools for developing REST APIs. These include FastAPI, Django REST Framework, and Flask.

In terms of testing, there are a few commonly used tools: Postman is widely recognized for its ability to test REST APIs in professional software development environments. It's used to ensure resources are being delivered and each facet of a REST API is performing as designed.

Alternatives to Postman include Insomnia, which some consider easier to work with and more developer friendly, and SOAP UI, which allows for testing of both REST APIs and SOAP APIs.

What are some real-world examples of REST APIs?

REST APIs can be seen in nearly every facet of the web. Simply by entering this website, there was a GET Request sent to a Server at the URL for the necessary HTML to display to the Client.

Most commonly as a developer, REST APIs are used to manipulate data from a particular database using the four main HTTP methods that map to CRUD operations.

Operations such as retrieving file data, accessing images, even hosting a web-site all require use of, commonly, REST APIs.

What are the overall advantages and disadvantages of RESTful web services?

Advantages

• REST is easy to learn with its use of HTTP and HTTP Methods
• REST allows for a wide range of data transfers such as JSON, XML, MIME
• Statelessness can allow for a simpler Client experience
• Responses are Cacheable, lowering bandwidth for Clients
• A wide ecosystem exist for its testing and development such as Postman
• REST APIs are scalable in nature due to the independence of Client and Server
• REST APIs can be used on the client-side by Web-apps, IOS apps, and most other client tech stacks due to the simple HTTP Request format and their lack of being tied to a client-side technology

Disadvantages

Learn More: View Exponent's complete system design interview prep course, to learn more about APIs and designing complex systems.

What is the difference between PUT, POST, and PATCH?

PUT and POST are very common HTTP methods. The key difference is that PUT is utilized to update a specified existing resource while POST is utilized to create a new resource. Additional differences may be found in the below table.

In addition to these two, there is the HTTP method PATCH. PATCH is another way of updating a particular resource. The difference between PATCH and PUT however is that PATCH alters only the data that is specified in the Request Body whereas PUT replaces the entire resource with a new resource comprised of the given data.

What is a payload in the context of a REST API?

Payload refers to any data that has been transferred via Request/Response through the REST API.

For instance, if the Client makes a GET Request, the Server will provide a Response with the appropriate payload.

In other cases, the Client may provide the payload such as in the case of a POST request where the Client is providing data to the Server. The Server would then provide a payload back to the Client, which would be the data on the resource created.

What is a REST Message?

The concept of messaging will refer to the back-and-forth communication via Request and Response by the Client and Server.

In addition, there is typically a message within every Response body associated with the provided Status Code. This message is one of the most important components of debugging and testing a REST API.

Some of the most common forms of messages include confirmation a resource was created or any Exceptions that were raised.

What are the core components of an HTTP Request?

There are 5 components in an HTTP Request:

Method: This may also be called the verb. Refers to operations such as GET, POST, PUT, DELETE etc.

URI: Used to identify the resource, typically using a URL.

Depending on the provided URL, one or many resources may be identified depending on the presence of an id.

REST APIs are typically designed for different behavior depending on whether a Request is made to GET/DELETE one resource vs. many resources.

HTTP Version: Indicates the HTTP version that is being used. This will typically be HTTP 1.1 or HTTP 2.0.

Request Header: Contains the request metadata: message format, cache settings, content format etc.

Request Body: Contains the content or data that is to be sent. Typically this is the most important aspect of creating a Request to a REST API as a developer.

For Methods such as POST and PUT, the body requires the entire data for the new resource.

What are the core components of an HTTP Response?

There are 4 components in an HTTP Response:

Status Code - Provides information on the success/failure of a request. 2XX codes indicate success, 4XX codes indicate client-side error, 5XX indicate server-side error

In many cases, the Status Code alone will be the most useful component of an HTTP Response when developing, testing, and debugging an API.


HTTP Version: Indicates the HTTP version that is being used. This will typically be HTTP 1.1 or HTTP 2.0.


Response Header: Contains response metadata: content length, content type, date etc.


Response Body: Contains returned data. Note: while there does not always have to be a Request body in a Request, a Response should always contain a Response body.

The below table reflect the contents that should exist in the Response for each major Request Method.

What is an idempotent method and why are they important?

When utilizing RESTful web-services, a client may make numerous requests to the server at a time. An idempotent method is one that yields the same Response regardless of how many times a request is sent.

For an example on an idempotent method:

Imagine pressing a button on a web page that made a GET Request to a resource called resource1. After the Nth press of said button, the API's response will be the same as the 1st press of said button.

REST APIs are designed on the principle that the Client should not depend upon previous API calls—hence why the REST architecture is made to be stateless.

Therefore, REST APIs should be made such that their methods (GET, POST, PUT, DELETE) are idempotent when possible.

Of the basic HTTP methods, POST is the only one that may not be idempotent as the Nth calling of a POST method will necessarily lead to the Nth resource created.

What is the difference between idempotent and safe HTTP methods?

While an idempotent method is one that can be called multiple times without changing responses, a safe method is one that does not change a resource. A safe method may read but not write: A GET method is considered to be safe.

Explain Caching in a RESTful architecture

Oftentimes, a Client may request the same data from a REST API many times. In this case, it's beneficial for the API's Response to be cached. This way less bandwidth needs to be used, and the Client may retrieve data quicker.

Each REST API contains specific meta-data related to the constraints on the caching of responses. Specifically the headers of Cache-Control and Expires specify what Responses may be cached, by whom, and for how long.

Caching is a corner stone of the REST API, and its implementation allows for lower latency and reduced load on a server.

What are Best Practices in developing a RESTful web-service?

Support JSON data transfer

JSON is arguable the most common form of data transfer on the web. As such, it's a best practice that JSON at least be supported within a REST API.

This can be done by setting Content-Type is set to application/json. This way, the API responds in a JSON format.

Use Proper Status Codes

Every outcome of a Request should be handled when designing a REST API. Ensure that the API always responds with a Status Code. A 500 code is better than timing out.

Furthermore, proper status codes should be used when able. If a resource was succesfully created, for instance, a code 201 should be utilized rather than the generic 200

Use URI hierarchy to represent the relationships of resources

The URI is a critical component of the REST API. As such, take care when creating its hierarchy. Be sure to design the hierarchy such that the relationship of the resources are accurately defined.

Additionally, be sure not to use an excessive amount of nesting when creating the URI as this can make the API more difficult to use.

Use Idempotent HTTP Methods

Idempotent HTTP Methods are necessary to implement in a REST architecture for reliability. Ensure that the handling of Requests do not at all rely on prior Requests.

Implement Caching

Caching is a key component of the RESTful architecture and should be utilized to reduce Server loads and bandwidth consumption.

It's equally important to maintain that data does not turn stale, and is updated regularly.

Incorporate Security Measures

Since REST APIs do not have security measures inherent to their architecture, Transport Layer Security (TLS) should be implemented.

TLS is a cryptographic security protocol that encrypts data between the Client and Server. Incorporation of this helps ensure secure channels for data to be transferred.

Beyond this, role-based access to resources should be implmented. This way, users don't have access to resources only a senior-developer or admin should be able to access.

More Resources

If you still want some more resources to help you prep for your upcoming interviews, we wouldn't blame you.

Luckily, there are dozens of other resources on Exponent to help you get ready for your upcoming software engineering, solutions architect, or system design interviews.

🧗 How to prepare for a Solutions Architect Interview (Questions & Answers)

💬 Get prepared with example interview questions

📖 Read through our company-specific interview guides

👯‍♂️ Practice your behavioral and product sense skills with our interview practice tool.