Interview Q&A

Short answer: It indicates the request was successful, and the server is returning the expected response body (e.g., GET request returning data).

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: It indicates that a new resource was successfully created. Usually returned after a POST request, along with a Location header pointing to the new resource.

Real-world example (ShopNest)

Creating an order is POST /api/orders → 201 with Location header. Fetching is GET /api/orders/{id} → 200 or 404.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: Returned when the request is malformed or invalid, such as: Missing required parameters. Invalid JSON format. Wrong data type provided.

Real-world example (ShopNest)

ShopNest exposes REST APIs for cart and checkout. Controllers stay thin; business rules live in application services.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: It means the client is not authenticated (missing/invalid credentials). The request cannot proceed without proper authentication (e.g., missing token).

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: 404 Not Found → The resource does not exist (or the client requested the wrong endpoint). 410 Gone → The resource used to exist but has been permanently removed.

Real-world example (ShopNest)

ShopNest exposes REST APIs for cart and checkout. Controllers stay thin; business rules live in application services.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: It means the client is authenticated but not authorized to access the resource. 👉 Example: A normal user trying to access an admin-only endpoint.

Real-world example (ShopNest)

Creating an order is POST /api/orders → 201 with Location header. Fetching is GET /api/orders/{id} → 200 or 404.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: It indicates the request was well-formed (valid syntax) but could not be processed due to semantic errors. 👉 Example: Submitting a form where email is valid format but already exists.

Real-world example (ShopNest)

ShopNest exposes REST APIs for cart and checkout. Controllers stay thin; business rules live in application services.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: It means the resource has not changed since the last request. Commonly used with caching to improve performance (client uses cached version).

Real-world example (ShopNest)

Creating an order is POST /api/orders → 201 with Location header. Fetching is GET /api/orders/{id} → 200 or 404.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: It indicates the server timed out waiting for the client’s request. 👉 Example: Client took too long to send data in a POST request.

Real-world example (ShopNest)

Creating an order is POST /api/orders → 201 with Location header. Fetching is GET /api/orders/{id} → 200 or 404.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: 503 indicates the server is temporarily unavailable (e.g., maintenance, overload). Best practices: Return a Retry-After header. Use monitoring/alerts to restore service quickly.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: 401 Unauthorized → Authentication required (client not logged in / invalid token). 403 Forbidden → Authentication is valid, but the user lacks permissions.

Real-world example (ShopNest)

Creating an order is POST /api/orders → 201 with Location header. Fetching is GET /api/orders/{id} → 200 or 404.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: A redirect tells the client to fetch a resource from a different URL. 301 Moved Permanently → Resource moved permanently (update bookmarks/links). 302 Found → Temporary redirect (use current URL for future requests).

Real-world example (ShopNest)

Creating an order is POST /api/orders → 201 with Location header. Fetching is GET /api/orders/{id} → 200 or 404.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: Statelessness means each client request to the server must contain all the necessary information to process it (like authentication token, parameters, body).

Explain a bit more

The server does not store client session state. 👉 Example in ASP.NET Core Web API: [HttpGet("profile")] public IActionResult GetProfile([FromHeader] string token) if (string.IsNullOrEmpty(token)) return Unauthorized(); // Token is validated each time (stateless, no session memory) return Ok(new { Name = "John Doe", Email = "john@example.com" }); }

Real-world example (ShopNest)

Creating an order is POST /api/orders → 201 with Location header. Fetching is GET /api/orders/{id} → 200 or 404.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: It means REST APIs separate the client (frontend/UI) and server (backend logic, database). The client is responsible for UI and user interactions. The server manages data, business logic, and security. This separation improves scalability and flexibility. 👉 Example: Client: React.js front-end making API calls. Server: ASP.NET Core Web API handling requests.

Real-world example (ShopNest)

Creating an order is POST /api/orders → 201 with Location header. Fetching is GET /api/orders/{id} → 200 or 404.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: Responses from the server should indicate whether they are cacheable or not, to improve performance and scalability. Clients and intermediaries can reuse cached responses. 👉 Example in ASP.NET Core: [HttpGet("products")] [ResponseCache(Duration = 60)] // Cache for 60 seconds public IActionResult GetProducts()

Example code

{
return Ok(new[] { "Laptop", "Mouse", "Keyboard" });
}

Real-world example (ShopNest)

Creating an order is POST /api/orders → 201 with Location header. Fetching is GET /api/orders/{id} → 200 or 404.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: The uniform interface ensures that REST APIs follow consistent conventions for communication, making them predictable and easy to use. Key aspects: Use of standard HTTP methods (GET, POST, PUT, DELETE). Resource identification via URIs. Resource representations (JSON, XML). Self-descriptive messages.

Real-world example (ShopNest)

Creating an order is POST /api/orders → 201 with Location header. Fetching is GET /api/orders/{id} → 200 or 404.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: In REST, resources (like users, products, orders) are identified with URLs instead of actions. 👉 Example in ASP.NET Core Web API: // Instead of action-based GET /getUser?id=1 // Use resource-based GET /users/1 This makes APIs cleaner and more intuitive.

Real-world example (ShopNest)

Creating an order is POST /api/orders → 201 with Location header. Fetching is GET /api/orders/{id} → 200 or 404.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: Statelessness → No server memory required for client sessions → Easy to scale horizontally. Layered System → Load balancers, caching layers can be added without changing API. Uniform Interface → Predictable, decouples client and server. Cacheability → Reduces server load.

Real-world example (ShopNest)

Creating an order is POST /api/orders → 201 with Location header. Fetching is GET /api/orders/{id} → 200 or 404.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: Each request and response should have enough metadata (headers, content type, status codes) to describe how to process it, without external context. 👉 Example in ASP.NET Core: return Ok(new { Id = 1, Name = "John", Links = new[] { new { Rel = "self", Href = "/users/1" } } }); Here, the response describes itself (content type = JSON, includes resource links).

Real-world example (ShopNest)

Creating an order is POST /api/orders → 201 with Location header. Fetching is GET /api/orders/{id} → 200 or 404.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: (With C# ASP.NET Core Web API example) Discoverability means clients can navigate and learn available actions through metadata or hypermedia links, without hardcoding routes. 👉 Example using HATEOAS in ASP.NET Core Web API: [HttpGet("users/{id}")] public IActionResult GetUser(int id)

Example code

{
var user = new { Id = id, Name = "Alice" };
var response = new
{ user, links = new[] { new { rel = "self", href = Url.Action("GetUser", new { id }) }, new { rel = "orders", href = Url.Action("GetUserOrders", new { id }) } } }; return Ok(response);
} The API response itself guides the client to related resources (user’s orders, profile, etc.). Q&A

Real-world example (ShopNest)

ShopNest exposes REST APIs for cart and checkout. Controllers stay thin; business rules live in application services.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: Discoverability means clients can navigate and learn available actions through metadata or hypermedia links, without hardcoding routes.

Explain a bit more

👉 Example using HATEOAS in ASP.NET Core Web API: [HttpGet("users/{id}")] public IActionResult GetUser(int id) { var user = new { Id = id, Name = "Alice" }; var response = new { user, links = new[] { new { rel = "self", href = Url.Action("GetUser", new { id }) }, new { rel = "orders", href = Url.Action("GetUserOrders", new { id }) } } }; return Ok(response); } The API response itself guides the client to related resources (user’s orders, profile, etc.). var response = new { user, links = new[] { new { rel = "self", href = Url.Action("GetUser", new { id }) }, new { rel = "orders", href = Url.Action("GetUserOrders", new { id }) } } }; return Ok(response); } The API response itself guides the client to related resources (user’s orders, profile, etc.). Q&A

Real-world example (ShopNest)

ShopNest exposes REST APIs for cart and checkout. Controllers stay thin; business rules live in application services.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: Use resource-based URLs (/users/1/orders) not action-based (/getUserOrders). ● Return proper status codes (200, 201, 400, 404, 500). Support pagination & filtering for large data. Implement authentication & authorization (JWT, OAuth2). Ensure statelessness. Provide versioning (v1, v2). Secure API with HTTPS only.

Real-world example (ShopNest)

Creating an order is POST /api/orders → 201 with Location header. Fetching is GET /api/orders/{id} → 200 or 404.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: Use nouns, not verbs → GET /users (not /getUsers). Use plural form → /users, /orders. Nested resources for relationships → /users/1/orders. Consistent naming conventions. Avoid exposing internal DB structure.

Real-world example (ShopNest)

ShopNest exposes REST APIs for cart and checkout. Controllers stay thin; business rules live in application services.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: How would you version a REST API? Versioning ensures backward compatibility when APIs change. Common approaches: URI versioning → /api/v1/users Header-based versioning → Accept: application/vnd.myapi.v1+json Query parameter → /users?version=1

Real-world example (ShopNest)

ShopNest mobile app sends a JWT Bearer token. The API validates it and uses the user id from claims to load that user’s cart only.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.

Short answer: Versioning ensures backward compatibility when APIs change. Common approaches: URI versioning → /api/v1/users Header-based versioning → Accept: application/vnd.myapi.v1+json Query parameter → /users?version=1

Real-world example (ShopNest)

ShopNest mobile app sends a JWT Bearer token. The API validates it and uses the user id from claims to load that user’s cart only.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.