Top REST API Interview Questions and Answers

REST (Representational State Transfer) is a set of rules that lets web apps communicate with each other easily using HTTP. It's important because it's simple, flexible, and works with existing web standards.

A REST API is like a waiter between your app and the server. You send it a request, and it brings you data in return. It uses URLs and HTTP methods like GET and POST.

RESTful web services are APIs that follow REST rules. They treat everything like a resource and use standard HTTP methods to manage them.

A resource is any data the API handles, like a user, product, or order. It’s identified by a URI.
GET /users/20

In /users/20, the resource is the user with ID 20.

A URI (Uniform Resource Identifier) is the path used to locate a resource in REST.
GET /books/5

Here, /books/5 is the URI pointing to the book with ID 5.
 

Stateless means the server doesn’t remember past requests. Each request must carry all the needed info. This helps scale the app easily.
GET /orders/2 with Authorization header 

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

HTTP status code lets us know whether a request worked or not]

• 200 → OK
• 201 → Created
• 400 → Bad Request
• 401 → Unauthorized
• 404 → Not Found
• 500 → Server Error 

JSON is simple, easy to read, and works well with most languages. It's also light, which makes responses faster.

POST is used to create a new resource. It doesn’t need a fixed ID.
PUT is used to update or replace a resource with a known ID.

Idempotency means that the same request can be made multiple times and it will have the same outcome without causing further changes. Idempotency ensures that the same operation can produce the same outcome if repeated (for example, retrying a request that failed will not have any unintended consequences). Idempotency is important when designing reliable and fault-tolerant APIs, especially in areas such as payment processing and data changes/updates.

Even if you run this request 5 times, the user with ID 10 will be deleted once. It won’t throw an error if it's already deleted, making it safe to retry.

Caching is a performance technique implemented in REST APIs that stores HTTP responses so that repeated requests can be served more quickly without the cost of hitting the server. Caching can help improve speed and efficiency by reducing latency, reducing load on the server, and reducing network traffic. Caching is impacted by HTTP headers, like Cache-Control, ETag, Last-Modified, and Expires, that provide data freshness while maintaining the statelessness characteristic of REST.

This means the response is valid for an hour. If requested again within that time, it’s loaded from the cache, not the server.

HTTP headers are key-value pairs that are processed in HTTP requests and responses. Headers contain metadata about the process and can assist in managing content-type, authentication, caching, and many more. Some commonly seen HTTP headers are Content Type, Authorization, Accept, Cache Control, and ETag, which help govern the correct way for a client and a server to interact.

Headers make the communication richer and more secure.

URI versioning: /v1/products (Simple but clutters URL)
Header versioning: Accept: application/vnd.api.v1+json (Clean URL, but harder to test in browser)
Query param: /products?version=1 (Flexible but not standard)

URI versioning is used mostly for clarity.
 

Use clear status codes and error messages.
404 Not Found - Resource doesn't exist
400 Bad Request - Input is invalid  
500 Internal Server Error - Something went wrong on the server
Also include a message body explaining the error.
 

Content negotiation refers to the action in REST APIs of the client and server agreeing on the data format to return in the response (JSON, XML, etc.). This happens through HTTP headers such as Accept and Content-Type that allow the client to define the format they desire and the server to respond in the format that is provided. This adds more flexibility to the APIs as well as a better experience for clients.

The server sends XML instead of JSON, based on what the client asked.

PUT replaces the entire resource

PATCH updates only specified fields

HATEOAS (Hypermedia as the Engine of Application State) is a RESTful constraint that allows clients to dynamically navigate APIs by using hypermedia links in responses. It provides actionable links like next, update, or delete to be included within the resource. This capability gives clients the opportunity to discover what actions can be performed at runtime, without the need to hardcode URIs.  HATEOAS allows for better discoverability, decoupling, and evolvability of REST APIs.

The GitHub REST API is used to fetch user details. The API responds with user info in JSON, like name, bio, and public repos. It’s helpful in projects to fetch GitHub data for profiles.

Rate limiting in REST APIs is a mechanism that limits the frequency of requests made by a client within a given time window. It guarantees fair use, prevents abuse like Denial of Service (DoS) attacks, and stabilizes the server. Rate limiting is typically implemented through HTTP headers: X-Rate-Limit-Limit, X-Rate-Limit-Remaining, and Retry-After. Servers generally use tokens or counters to implement rate limiting.

If a client sends too many requests, the server can respond with a 429 Too Many Requests status. This keeps the service stable and fair for everyone.

REST services are stateless, which means each request is treated independently. This makes it easier to distribute requests across multiple servers.

Because the server doesn’t remember previous interactions, scaling becomes simpler.

A simple and common way to secure REST APIs is by using OAuth and JWT (JSON Web Token). OAuth helps manage trusted access, while JWT lets users stay logged in securely without sending their password every time.

Here, the token proves the user is allowed to access the API. It keeps the process secure and avoids sending login details again and again.

REST APIs may face several security issues as described here.

XSS (Cross-Site Scripting): Happens when attackers inject malicious scripts into web pages. To fix this, escape user inputs and set Content Security Policy (CSP) headers to block unsafe scripts.

CSRF (Cross-Site Request Forgery): Tricks users into performing unwanted actions while logged in. To fix this, use CSRF tokens and set cookies with the SameSite flag to prevent cross-site requests.

Injection Attacks (like SQL Injection): Attackers send dangerous input that gets executed by the server. To fix this, always sanitize inputs and use prepared statements instead of raw queries. Prepared statements are a safe way to run database queries. Instead of adding user input directly into the SQL, you send the query and data separately. This way, the input is treated as data rather than as code. So attackers can't inject harmful SQL. They help prevent SQL injection and keep your database secure.

# Vulnerable to SQL injection

# Good method (using a prepared statement)

Insecure Data Transfer: Sensitive data can be stolen if sent over unprotected connections. To fix this, always use HTTPS to encrypt data in transit.

These steps help secure your APIs and protect user data.
 

Rate limiting restricts how many requests a user can make in a given time. It's often done using IP tracking or API tokens.

Tools like Redis, API Gateway, or NGINX can handle it.

The Richardson Maturity Model (RMM) is a framework created by Leonard Richardson to describe how closely a web API follows the principles of REST (Representational State Transfer). It breaks down RESTful API design into four levels of maturity, based on how the API uses URIs (Uniform Resource Identifiers), HTTP methods (also called HTTP verbs), and hypermedia controls (also known as HATEOAS, or Hypermedia as the Engine of Application State).

The higher the level is the more your API follows REST best practices.

Level 0 – One URL for everything

Consider a restaurant where you write all your orders on one paper and hand it to one person. No menu, just tell them what you want. That’s Level 0. You send all requests to just one URL and tell it what to do in the body.

Level 1 – Use URLs for different purposes

Now, consider the restaurant has different counters. Pizza, drinks, and desserts. You go to the right one. That’s Level 1. You split your API into different URLs (resources), like /users, /orders, etc. But you still use only one method, like POST.

Level 2 – Use proper HTTP methods

Now the restaurant not only has counters, but each counter knows whether you want to order, update, or cancel. In Level 2, your API uses GET to read, POST to create, PUT to update, and DELETE to delete.

Level 3 – Guide the client with links (HATEOAS)

Finally, in Level 3, the server helps the client by saying, "Here’s what you can do next." Just like an app showing buttons like “Edit” or “Delete,” the API includes helpful links in its response.

REST APIs use tokens, API keys, or sessions to check who’s making the request and if they’re allowed to do it. For example, a common way is to send a token in the request header:
 

OAuth is often used to control what users can access, while JWT (JSON Web Token) is used to verify their identity securely.

To test REST APIs, we use tools that help us send requests and check the responses. These tools help check the response body, status codes, headers, and error messages.

Postman: An excellent tool for manual testing. You can send GET, POST, PUT, and DELETE requests and see the response.

cURL: A command-line tool to quickly test APIs.
curl -X GET https://api.site.com/posts // Sends a GET request to fetch posts

Jest + Supertest (for Node.js) or Rest Assured (for Java) are used for automated testing in code. These help run tests repeatedly to check if APIs behave as expected.

To create effective REST API documentation, keep it updated and clear.
show sample requests and responses, explain parameters and errors, and use Swagger or Postman for auto-generated docs. Good docs help developers understand and use the API quickly.

• REST can be chatty, meaning it may need various requests to get all the data, which can slow down the process.
• It’s stateless, so the server doesn’t remember previous interactions. Clients have to manage everything, like sessions or progress.
• REST is less structured than something like SOAP, which can lead to inconsistencies
• It’s not ideal for real-time features like live chat or instant notifications. In such cases, we can go for technologies like WebSockets.

REST and SOAP are two different ways to build and use web services, but they work very differently.

REST is easier and more flexible. It works only over HTTP, just like how your browser communicates with websites. It doesn’t need any strict rules or fixed agreements (called contracts) between the client and server, so it’s lightweight and faster to use. You can send data in different formats, like JSON, which is easy to read and write. REST is simpler and faster, good for most web APIs.

SOAP, on the other hand, is more strict. It can work over different types of networks, not just HTTP. It always uses XML to send data, which is heavier and more complex. SOAP also uses something called a WSDL contract, which defines exactly how communication should happen. That makes it more structured but harder to work with. However, SOAP has strong built-in security features. SOAP is more secure and formal, often used in enterprise or banking systems.