No matter which programming language or technology you’re working with, you’ve probably encountered a REST application programming interface (API). REST stands for Representational State Transfer, which is the one of the most widely-used architectural styles for web services, microservices, and APIs today. APIs that follow the REST architectural style are considered REST APIs.

Whether you’re a junior or senior developer, you may be asked questions about REST API in an interview. To help you ace your next interview, we’ll discuss some common REST API interview questions and answers.

We’ll cover:

• 13 REST API interview questions you need to know
  • 1. What is REST?
  • 2. What is a REST API?
  • 3. Describe the 5 constraints of the REST architectural style, and their benefits.
  • 4. What is the optional architectural constraint of REST?
  • 5. Explain the constraints of a uniform interface.
  • 6. What is CRUD?
  • 7. Explain the HTTP request methods supported by REST, and when they are used.
  • 8. What’s the difference between PUT and POST methods?
  • 9. Explain what statelessness means in REST.
  • 10. What are the advantages and disadvantages of a REST API?
  • 11. What's the difference between AJAX and REST?
  • 12. What's the difference between SOAP and REST?
  • 13. Explain HTTP response status codes.
• Wrapping up and next steps

13 REST API interview questions you need to know

1. What is REST?

REST stands for Representational State Transfer. REST is an architectural style for web development. REST architecture lays out guidelines for the transfer of resource representations between clients and servers on the web.

2. What is a REST API?

A REST API or RESTful API is a web API that conforms to the REST architecture style.

3. Describe the 5 constraints of the REST architectural style, and their benefits.

In case they ask for 6 constraints, see the following question about the optional constraint.

A truly RESTful API must conform to the five REST architectural constraints:

• Uniform interface:
  • Interface between client and server that allows for standardized client-server communication in a single language
  • Necessary for the decoupling of client and server
• Client-server:
  • Client-server model, for separation of concerns between client and server
  • Permits client and server to operate and evolve independently
  • Supports portability and scalability
• Stateless:
  • Refers to stateless communication protocol, wherein the server stores no information about session states
  • Improves performance by reducing server load
• Cacheable:
  • Servers mark their responses as cacheable or non-cacheable
  • Clients and intermediaries are able to cache server responses
  • Reduces client-server interaction, supports scalability and performance
• Layered system:
  • Layers between client and server, can consist of intermediaries such as proxy servers or load balancers
  • Layers have separate responsibilities but are able to interact with each other
  • Supports system scalability and security

4. What is the optional architectural constraint of REST?

Code on demand is the optional constraint of RESTful architecture. Code on demand allows the server to send executable code (scripts or applets) to a client upon client request.

Advantage: Extends client functionality, since client can download features after deployment


Disadvantage: Reduces visibility, which is why it’s considered optional


Examples: Java applets and JavaScript

5. Explain the constraints of a uniform interface.

A uniform interface is needed to decouple the client from the server.

There are four necessary constraints to achieving uniform interface:

• Identification of resources: Client requests must identify resources using uniform resource identifiers (URIs)
• Manipulation of resources through these representations: When clients receive a resource representation from the server, they have all information necessary to be able to modify resource state
• Self-descriptive messages: Messages contain all information necessary for recipient to interpret it, including metadata
• Hypermedia as the engine of application state: Hypermedia (such as HTML) is the medium for client-server interaction, and the client requires no API-specific documentation to understand server responses

6. What is CRUD?

CRUD is an acronym for the four basic operations used in relational database management system (RDBMS).

Each operation in CRUD relates to an HTTP method that REST supports.

• Create: POST
• Read: GET
• Update: PUT
• Delete: DELETE

7. Explain the HTTP request methods supported by REST, and when they are used.

REST APIs are based on HTTP requests or verbs, which each perform a different task.

REST supports the following HTTP requests:

• GET method: Request data from server
• POST method: Submit data to create new resource on server-defined URL
• PUT method: Submit data to update a resource at client-defined URL
• DELETE method: Remove resource from server
• OPTIONS method: Return request methods supported by a service
• HEAD method: Return meta information such as response headers
• PATCH method: Modify part of the resource on the server

8. What’s the difference between PUT and POST methods?

This question can stump some developers. Being able to explain this will help you stand out as someone who actually knows what they’re talking about.

Here are the differences between PUT and POST:
PUT:

• Idempotent (i.e. multiple requests will yield same result)
• PUT responses aren’t cacheable
• Updates or replaces target resource with request's payload

POST:

• Not idempotent (i.e. multiple requests will yield multiples of the same resource)
• POST responses can be cacheable, provided proper cache-control header
• Request's payload is processed by the web server based on target resource

Understanding idempotency: An example of an idempotent operation would be the operation of multiplying a number by one. No matter how many times you multiply five by one, you’ll get the same result.

9. Explain what statelessness means in REST.

Statelessness means that the client and server don’t store information about each other’s state. Since the server stores no information, it treats each client request as a new request.

As a consequence, the following conditions would apply:

• The client request contains all information required for the server to process the request
• Client application is responsible for storing session state

10. What are the advantages and disadvantages of a REST API?

It’s important to know the pros and cons of a RESTful API.

Advantages include:

• Designed for high performance, portability, reliability, and scalability
• Client-server separation allows each to individually operate and scale
• Easy to test and adapt to various environments
• Easy to learn as it uses HTTP protocol
• Supports various data transfer technologies including JSON, XML, YAML, images, and more
• Uses less bandwidth than other methods, such as Simple Object Access Protocol (SOAP) technology

Disadvantages include:

• Doesn’t enforce security practices
• HTTP method limits you to synchronous requests
• Due to statelessness, you might be unable to maintain state (e.g. in sessions)

11. What's the difference between AJAX and REST?

The distinction can confuse beginner developers, so it’s helpful to know the difference.

An AJAX client can make a RESTful request to a REST API (e.g. a get request), but AJAX isn’t an architectural style. It’s a web development technique for client-side applications. REST APIs can be accessed by AJAX clients, but they aren’t inherently implemented with AJAX.

12. What's the difference between SOAP and REST?

Although some REST APIs use SOAP protocols, REST and SOAP are entirely different approaches to building APIs. Interviewers may ask this to assess your depth of understanding.

Here are some of the differences between SOAP and REST.
SOAP:

• Protocol
• Data format is limited to XML
• Heavyweight and requires more bandwidth
• Calls can’t be cached

REST:

• Architectural style
• Allows various data formats including plain text, HTML, XML, JSON, and YAML
• Lightweight and requires less bandwidth
• Calls can be cached

13. Explain HTTP response status codes.

HTTP response codes indicate the result of client requests.

Common HTTP status codes include:

• 200: Successful request
• 201: Entity or entities created from successful request
• 400: Bad request. Invalid client request.
• 401: Unauthorized. User isn’t authorized to access a resource and may be unauthenticated
• 403: Forbidden. User isn’t authorized to access a resource, user is authenticated
• 404: Not found. Resource not found
• 500: Internal server error. Generic server error
• 502: Bad gateway. Response from upstream server is not valid
• 503: Service unavailable. Result of server-side issue, including overload or system failure

Wrapping up and next steps

Congratulations! You’re now prepared with some common REST API interview questions and answers. Where you go from here depends on your goals.

For interview prep, check out Interview Prep with Educative. Here, you’ll find all our resources for interview prep in one place, from tutorials and practice problems, to tips from industry experts.

To get hands-on with REST APIs, check out one of our interactive REST API courses:

• Learn REST and SOAP API Test Automation in Java
• Creating a CRUD REST API with Deno & Oak
• Build a REST API Using Python and Deploy it to Microsoft Azure

Happy learning!

Continue reading about APIs and interview prep on Educative

• What are REST APIs? HTTP API vs REST API
• 3 Features beginner devs overlook when building APIs
• 8 job search tips to get a developer job you love

Start a discussion

Which REST API interview questions are you practicing? Was this guide helpful? Let us know in the comments below!