REST API interview questions
The Postman Team
August 23, 2023
APIs are the building blocks of modern applications, and it’s becoming more common to see “knowledge of REST APIs” listed as
a requirement in job descriptions—even for non-developer roles. In fact, Postman’s 2023 State of the API Report found that 53%
of people who work with APIs are non-developers. So, whether you’re applying to be an engineer, product manager, data
analyst, or customer success manager, these answers to ten of the most common REST API interview questions will help you
navigate the interview process with confidence.
1. What is REST?
REST (Representational State Transfer) is the most commonly used architectural style for building web services and APIs. In a
RESTful architecture, resources are identified by URIs (Uniform Resource Identifiers), and operations are performed on those
resources using standard HTTP methods. The state of a resource is represented in JSON or XML, which is transferred between
the client and server in the HTTP request and response bodies.
2. What is the relationship between HTTP and REST?
HTTP, which stands for Hypertext Transfer Protocol, is the dominant protocol for transmitting data between clients and servers
on the internet. HTTP operates on a stateless request-response model, in which the client sends a request to the server and
the server responds accordingly—without any knowledge of the client’s previous requests. REST emphasizes standardized,
stateless interactions between clients and servers, which makes HTTP the ideal choice for implementing RESTful principles.
3. What is the difference between REST and SOAP?
REST and SOAP are two different architectural styles for building APIs. REST is a highly flexible approach that uses standard
HTTP methods to interact with resources that are represented in JSON or XML. In contrast, SOAP is an XML-based messaging
protocol that is used to transfer data between distributed applications and systems, and it follows a very strict structure. REST
is more popular than SOAP, but SOAP is still used in many enterprise-scale systems that require advanced security and error
handling features.
Learn more about the differences between REST and SOAP.
4. What are HTTP headers, and which ones are most commonly used?
HTTP headers contain the metadata that is included in an API request or response. These key-value pairs provide essential
details that help the API client and server communicate more effectively—and enable developers to customize and optimize the
API’s behavior.
Some of the most common request headers are Accept , which defines the media types that the client is able to accept from
the server; Authorization , which is used to send the client’s credentials to the server when the client is attempting to access
a protected resource; and Content-Type , which defines the media type in the request body.
The server also includes HTTP headers in its response to the client. Some of the most common response headers include
Cache-Control , which defines how the response should be cached, and Set-Cookie , which instructs the client to store a
cookie with the specified attributes.
5. What is a resource in a RESTful context?
A REST resource is any object or group of objects that can be accessed through a dedicated API endpoint. For instance, a
simple blog API may have an author resource. Individual authors may be accessed via the /authors/:id endpoint, while the
collection of all authors may be accessed via the /authors endpoint.
In a well-designed RESTful API, resources and their associated endpoints should follow standard naming conventions and
represent a logical entity that makes sense in the context of the application. Proper representation of resources is crucial for
building an API that can be easily maintained and consumed.
6. What are some defining features of REST APIs?
REST APIs have several characteristics that promote efficiency, scalability, and interoperability. One key feature is
statelessness, which means that every request from the client includes all necessary information, and the server doesn’t store
any client-specific data. This behavior allows servers to handle client requests without managing complex session data, which
simplifies server design and promotes horizontal scalability.
Another important aspect of REST APIs is the separation of concerns between the client and server. A REST API client is
responsible for the user interface and user experience, while the API server handles request processing and resource
management. This clear delineation ensures modularity and enables each component to evolve independently.
Finally, all REST APIs have a uniform interface in which endpoints are accessed with an established set of HTTP methods. This
consistency promotes API integration, as any client that supports HTTP can use a RESTful API—regardless of its platform or
programming language. The uniform interface also makes REST APIs easier to maintain and accelerates the onboarding process
for new consumers.
7. What is the difference between the PUT and PATCH methods?
The PUT and PATCH methods are both used to modify resources, but they handle updates differently. The PUT method works
by replacing a resource with the data that is included in the request body. This means that any fields or properties not included
in the request body are deleted, and any new fields or properties are added.
In contrast, the PATCH method is used for making partial updates to a resource. For instance, if you have a movie resource
with fields for title , year , and rating , but you only want to update the rating , you could use the PATCH method to send
a request that only includes the new value for the rating field. The rest of the resource would remain unchanged. This
behavior reduces the amount of data that must be transferred, which makes PATCH more efficient than PUT.
8. What is idempotency in a RESTful context?
An HTTP method is considered idempotent if it will result in the same outcome no matter how many times it is executed. All
read-only methods are idempotent, as are PUT and DELETE. However, POST and PATCH are not idempotent. POST is not
idempotent because calling it multiple times will result in multiple resources being created. PATCH can be idempotent, but it is
not necessarily so. For instance, a PATCH request may increment a specific field every time it is called, which would modify the
resource every time.
9. What are the most common HTTP status codes?
HTTP status codes are three-digit numbers included in the server’s response that indicate the result of a client’s request. Some
of the most common HTTP status codes include:
200 OK: The request was successful, and the response includes the requested data.
201 Created: The request was successful, and the server has created a new resource with the provided data.
204 No Content: The request was successful, but there is no additional data to send in the response. This code is often used in
response to DELETE requests.
400 Bad Request: The server cannot understand the request due to a client error, malformed syntax, or invalid parameters.
401 Unauthorized: The client lacks valid credentials to access the requested data or perform the desired action.
403 Forbidden: The client does not have permission to access the requested resource, even with valid authentication
credentials.
404 Not Found: The server cannot find the requested resource or endpoint.
500 Internal Server Error: The server encountered an unexpected issue.
503 Service Unavailable: The server is not ready to handle the request, often due to overload or maintenance.
504 Gateway Timeout: The server acting as a gateway or proxy did not receive a timely response from the upstream server.
10. What are the advantages and drawbacks of statelessness in REST?
Statelessness is a hallmark trait of REST APIs, and it has many benefits. REST API servers don’t need to manage session data,
which allows them to handle a large number of concurrent requests and supports horizontal scaling. This also leads to
streamlined server logic and faster response times.
Statelessness has a few drawbacks, as well. Requests to a REST API may have larger payloads, as the client must include all of
the necessary information. This may have a negative impact on network performance. Statelessness may also require clients to
handle retries in the case of network or server failures, as there is no server-side context to help with these error scenarios.
+67
Tags: API 101 REST REST API Tutorials
The Postman Team
Today, more than 30 million developers use the Postman API Platform. Postman simplifies each step of the API lifecycle and
streamlines collaboration so you can create better APIs—faster.
View all posts by The Postman Team →
What do you think about this topic? Tell us in a comment below.
Comment
Your name
Your email
Write a public comment
Post Comment
5 thoughts on “REST API interview questions”
mischl
August 25, 2023
often seen status code
429 Too Many Requests: Rate limit exceeded. Wait before retrying and reduce the rate of requests
Kristen Stahl
January 25, 2024
Very informative
Sukh
February 26, 2024
Great article!
concise, informative and easy to follow
+1
Marvan
March 6, 2024
Great article. However, I think this part is a bit misleading:
‘and Content-Type, which defines the media type in the request body.’
When reading this, I got the impression that `Content-Type` is only used in request bodies, which isn’t right.
+2
Rahul Somdatt Bhatt
July 22, 2024
Loved the detailed article!
Also, I liked how you connected the statelessness to horizontal scaling in last question.
You might also like
Announcing Postman has acquired Orbit
Abhinav Asthana
Since day one, Postman has been about developer productivity. It started by saving developers from repeatedly typing the same
commands and grew…
Read more →
How Postman enhances Amazon AWS DevOps
Sandeep Murusupalli
The Postman API Platform empowers developers to optimize their API production and consumption lifecycle while enabling
enterprises to offer a collaborative, secure…
Read more →
How to build an API in Python
Guest Author
This is a guest blog post by Stefan Djokic, tech content creator and .NET senior software engineer. An API, short for “application…
Read more →
Postman v11 is here!
It's jam-packed with updates to help you collaborate on your APIs, augment yourself with AI, and more.
See what's inside v11 →
Product Company
What is Postman? About
API Repository Careers and culture
Tools Press and media
Governance Contact us
Workspaces Partner program
Integrations
Legal and Security
Enterprise
Terms of Service
Plans and pricing
Trust and Safety
Download the app
Privacy policy
Support Center
Cookie notice
Privacy choices
API Categories Social
App Security Twitter
Payments LinkedIn
Financial Services GitHub
DevOps YouTube
Developer Productivity Twitch
Data Analytics
Communication
Artifical Intelligence