Interview Q&A

• Implement global exception handling using middleware to catch unhandled

exceptions.

• Return consistent and meaningful error responses.
• Log errors for debugging and monitoring.

Example in ASP.NET Core:

app.UseExceptionHandler(appError =>

appError.Run(async context =>

context.Response.StatusCode = 500; // Internal Server Error

context.Response.ContentType = "application/json";

var contextFeature =

context.Features.Get<IExceptionHandlerFeature>();

if(contextFeature != null)

// Log exception (use ILogger)

await context.Response.WriteAsync(new

StatusCode = context.Response.StatusCode,

Message = "Internal Server Error.",

Detail = contextFeature.Error.Message

}.ToString());

});

});

Review the concept and prepare a concise verbal explanation with a real project example.

• Statelessness → Each request is independent; the server doesn’t store client state.
• Client-Server Architecture → Separation of concerns between client UI and server

logic.

• Uniform Interface → Standard HTTP methods and URIs.
• Cacheable → Responses can be cached to improve performance.
• Layered System → APIs can use intermediaries (like load balancers, proxies).
• Resource-based → Everything is treated as a resource (like users, orders,

products).

• Return a structured JSON response with:
• status → HTTP status code
• error → Short message
• details → Optional for debugging

Example:

"status": 400,

"error": "Bad Request",

"details": "Email is required"

Review the concept and prepare a concise verbal explanation with a real project example.

• REST → Lightweight, uses HTTP, usually JSON, easy to use, stateless.
• SOAP → Protocol-based, uses XML, more complex, built-in security & transactions.
• REST is more flexible and widely used for web and mobile apps.

• 404 Not Found indicates the requested resource does not exist.
• Use it when a client requests an invalid ID or non-existent resource.
• Helps clients gracefully handle missing data.

Example in ASP.NET Core:

var user = dbContext.Users.Find(id);

if (user == null)

return NotFound(new { status = 404, error = "User not found" });

Client sends token in Authorization header:

Authorization: Bearer <token>

HTTP provides the transport mechanism and defines methods:

• GET → Retrieve data
• POST → Create resource
• PUT → Update resource
• DELETE → Remove resource
• PATCH → Partial update

• Use model validation with data annotations.
• Return 400 Bad Request with a list of validation errors.

Example:

public class UserModel

[Required(ErrorMessage = "Email is required")]

[EmailAddress(ErrorMessage = "Invalid email format")]

public string Email { get; set; }

[Required]

[MinLength(6, ErrorMessage = "Password must be at least 6

characters")]

public string Password { get; set; }

// Controller action

[HttpPost("register")]

public IActionResult Register([FromBody] UserModel model)

if (!ModelState.IsValid)

var errors = ModelState.Values.SelectMany(v =>

v.Errors).Select(e => e.ErrorMessage);

return BadRequest(new { status = 400, error = "Validation

Failed", details = errors });

return Ok("User registered successfully");

• Structured logging with libraries like Serilog, NLog, or built-in ILogger.
• Log requests and responses, including headers and payloads (avoid sensitive info).
• Use correlation IDs to trace requests across services.
• Centralize logs using ELK Stack, Seq, or Azure Application Insights.
• Log different levels: Information, Warning, Error, Critical.

Example using ILogger in ASP.NET Core:

private readonly ILogger<MyController> _logger;

public MyController(ILogger<MyController> logger)

_logger = logger;

[HttpGet("{id}")]

public IActionResult GetUser(int id)

_logger.LogInformation("Fetching user with id {UserId}", id);

try

var user = dbContext.Users.Find(id);

if (user == null)

_logger.LogWarning("User with id {UserId} not found",

id);

return NotFound();

return Ok(user);

catch (Exception ex)

_logger.LogError(ex, "Error fetching user with id {UserId}",

id);

return StatusCode(500, "Internal Server Error");

This covers all core aspects of error handling and debugging for REST APIs.

Review the concept and prepare a concise verbal explanation with a real project example.

An endpoint is a specific URL that represents a resource in a REST API.

👉 Example:

→ Represents user with ID 1.

Stateless means the server does not store client session data. Each request must

contain all the necessary information (like authentication tokens). This makes APIs scalable

and reliable.

Review the concept and prepare a concise verbal explanation with a real project example.

• Platform-independent (works across web, mobile, IoT).
• Simple, flexible, and scalable.
• Uses existing HTTP infrastructure.
• Lightweight (JSON/XML).
• Supports caching for better performance.

• Easier to learn & implement.
• Supports multiple formats (JSON, XML, plain text).
• Faster (less overhead).
• Works seamlessly with modern web & mobile apps.
• Better performance due to caching & statelessness.

Suppose we have a User Service API:

• GET /users → Get all users
• GET /users/1 → Get user with ID=1
• POST /users → Create a new user
• PUT /users/1 → Update user with ID=1
• DELETE /users/1 → Delete user with ID=1

This shows how CRUD operations map directly to HTTP methods.

In REST, everything is modeled as a resource (users, products, orders). Each resource is

identified by a URI and can be manipulated using standard HTTP methods.

HATEOAS (Hypermedia As The Engine Of Application State) means responses contain

links to related actions/resources.

👉 Example:

"id": 1,

"name": "John",

"links": [

{ "rel": "self", "href": "/users/1" },

{ "rel": "orders", "href": "/users/1/orders" }

This helps clients navigate APIs dynamically.

Common methods:

• API Keys → Simple tokens.
• Basic Auth → Username & password (not secure without HTTPS).
• OAuth 2.0 / OpenID Connect → Standard protocols for secure access.
• JWT (JSON Web Tokens) → Widely used for stateless authentication.

Middleware is software that sits between client requests and server responses.

Used for:

• Logging
• Authentication & Authorization
• Request validation
• Error handling
• Rate limiting

🔹 HTTP Methods & Verbs – REST API Interview Q&A

• GET → Used to retrieve data, should not modify server state, and can be

cached/bookmarked.

• POST → Used to create new resources or submit data. It modifies server state, is

not idempotent, and cannot be cached.

• 200 OK → If the resource was successfully deleted and a response body is returned.
• 204 No Content → If the resource was deleted but no body is needed.
• 404 Not Found → If the resource does not exist.

• Safe → Because it only retrieves data without modifying server state.
• Idempotent → Multiple GET requests have the same result; no side effects occur.

Yes. If the resource does not exist, PUT can create it at the specified URI. Example:

👉 PUT /users/100 → If user 100 doesn’t exist, it will be created.

Idempotency means multiple identical requests have the same effect as one.

• PUT → Updating a resource with the same data multiple times results in no further

change.

• DELETE → Deleting a resource repeatedly still results in it being deleted.

• PATCH → Updates only the specified fields (partial update).
• PUT → Replaces the entire resource representation.

👉 Example:

• PATCH /users/1 { "email": "new@email.com" } → Updates only the

email.

• PUT /users/1 { "name": "John" } → May overwrite other fields like email if

not included.

The GET method is used to fetch data because it is safe, idempotent, and optimized for

retrieval operations.

🔹 HTTP Status Codes – REST API Interview Q&A

HTTP status codes are 3-digit numbers returned by the server to indicate the result of a

client request.

They are important because they:

• Communicate success, failure, or redirection.
• Help clients handle responses consistently.
• Provide debugging and monitoring information.

It indicates the request was successful, and the server is returning the expected response

body (e.g., GET request returning data).

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.

Returned when the request is malformed or invalid, such as:

• Missing required parameters.
• Invalid JSON format.
• Wrong data type provided.

It means the client is not authenticated (missing/invalid credentials). The request cannot

proceed without proper authentication (e.g., missing token).

• 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.

It indicates a server-side failure (unexpected error, crash, or unhandled exception). It’s a

generic error and should be logged for debugging.

It means the client is authenticated but not authorized to access the resource.

👉 Example: A normal user trying to access an admin-only endpoint.

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.

It means the resource has not changed since the last request. Commonly used with

caching to improve performance (client uses cached version).

It indicates the server timed out waiting for the client’s request.

👉 Example: Client took too long to send data in a POST request.

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.

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

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).

🔹 REST Principles & Architecture – Interview Q&A

Statelessness means each client request to the server must contain all the necessary

information to process it (like authentication token, parameters, body). 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"

});

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.

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()

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

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.

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.

• 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.

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).

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)

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.).

🔹 API Design Best Practices – REST API Interview

Q&A

• 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.

• 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.

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

• Lightweight and easy to parse.
• Language independent.
• Human-readable.
• Supported natively by JavaScript and most frameworks.

• Consistency in naming and responses.
• Error handling with meaningful messages.
• Security (HTTPS, JWT, OAuth2).
• Scalability (statelessness, caching).
• Performance (pagination, filtering).
• Documentation (Swagger/OpenAPI).

Return proper status codes and a structured error object:

👉 Example in ASP.NET Core:

"status": 400,

"error": "Invalid Request",

"details": "Email field is required"

• Prevents large payloads.
• Improves performance and response times.
• Reduces server and network load.

👉 Example: GET /users?page=2&limit=20.

• Use throttling to limit requests per minute/hour per client.
• Return 429 Too Many Requests.
• Provide Retry-After header.
• Tools: API Gateway, NGINX, Middleware.

• Authentication → API Keys, JWT, OAuth2.
• Authorization → Role-based access control.
• Always use HTTPS.
• Validate input & sanitize data.
• Prevent SQL injection, XSS, CSRF.

• Provide versioning.
• Send Deprecation warning headers.
• Maintain old versions temporarily.
• Give developers migration guides.

An API key is a unique token used to authenticate requests.

👉 Example:

GET /users?apikey=12345

Best practice: Send in headers → Authorization: ApiKey 12345.

Pros:

• Secure delegated access.
• Widely adopted (Google, Facebook, GitHub).
• Works well for 3rd-party apps.

Cons:

• Complex implementation.
• Requires token management.
• Overhead for small/simple APIs.

• GET, PUT, DELETE → Ensure repeated requests produce the same result.
• Avoid side effects on repeated requests.
• Use unique request IDs for POST (to prevent duplicate creation).

• SQL Injection
• Cross-Site Scripting (XSS)
• Cross-Site Request Forgery (CSRF)
• Broken Authentication
• Insecure Direct Object References (IDOR)
• Unencrypted data transmission

• Always use parameterized queries / ORM (EF Core).
• Validate and sanitize input.
• Apply least privilege on DB users.

👉 Example in EF Core:

var user = db.Users.FirstOrDefault(u => u.Email == email);

• Malicious sites could misuse APIs if CORS is too permissive.
• Always restrict origins (Access-Control-Allow-Origin).
• Avoid * in production.
• Use tokens for security.

• Use structured logging (Serilog, NLog).
• Log important events (auth failures, errors, requests).
• Implement monitoring tools (Application Insights, ELK Stack).
• Add correlation IDs for tracing requests.

• URI Versioning → /api/v1/users
• Header Versioning → Accept: application/vnd.myapi.v2+json
• Best practice: URI versioning for clarity.

• XML
• YAML
• CSV
• Protocol Buffers (gRPC)
• Plain text

• Synchronous → Client waits until the server responds (blocking).
• Asynchronous → Server processes request in background and may send response

later (via polling, callbacks, or webhooks).

Webhooks are server-to-server callbacks triggered by events.

👉 Example: Stripe API calls your endpoint /payment/confirmed when a payment

succeeds.

• Used for CORS preflight requests.
• Tells the client which HTTP methods and headers are allowed.

👉 Example Response:

Allow: GET, POST, PUT, DELETE

Access-Control-Allow-Origin: *

• Always return limited results (avoid huge payloads).
• Provide page and limit parameters → /users?page=2&limit=20.
• Return metadata → { "page": 2, "totalPages": 10 }.
• Support cursor-based pagination for large datasets.

🔹 Advanced REST API Design – Interview Q&A

• Provides clear usage guidelines for developers.
• Reduces onboarding time for new teams.
• Ensures consistency across different services.
• Helps with discoverability of endpoints, parameters, request/response formats.

👉 Tools: Swagger (OpenAPI), Postman, Redoc.

• Use tools like Postman Collections, Newman, RestAssured (Java), Supertest

(Node.js), xUnit/NUnit (C#).

• Integrate tests into CI/CD pipelines (Jenkins, GitHub Actions, Azure DevOps).
• Automate unit, integration, and load tests.
• Ensure regression testing after deployments.

• Async Processing → Return 202 Accepted with a status URL (/jobs/{id}).
• Client polls the status endpoint until job is complete.
• Optionally use Webhooks for notifying clients.

👉 Example: File processing, report generation.

• API Gateway is a single entry point for APIs in a microservices architecture.
• Handles routing, load balancing, authentication, rate limiting, logging,

monitoring.

• Examples: Kong, NGINX, AWS API Gateway, Azure API Management.
• Use when:
• You have multiple microservices.
• Need centralized authentication/security.
• Need rate limiting or monitoring.

• Configure CORS policy on the server.
• Allow specific origins, headers, and methods.

👉 Example in ASP.NET Core:

services.AddCors(options =>

options.AddPolicy("MyPolicy",

builder => builder.WithOrigins("

.AllowAnyHeader()

.AllowAnyMethod());

});

• Apply with app.UseCors("MyPolicy");.

• Rate limiting restricts the number of API requests per user/IP in a given time.
• Prevents abuse (DDoS, brute force).
• Ensures fair usage and protects backend systems.
• Return 429 Too Many Requests with Retry-After header.

👉 Example: 100 requests/minute per API key.

• Use an API Gateway for routing and orchestration.
• Implement service discovery (Consul, Eureka).
• Use message queues/event buses (RabbitMQ, Kafka) for async communication.
• Apply circuit breakers (Polly in .NET) to handle failures.
• Implement distributed tracing (Jaeger, Zipkin, OpenTelemetry).

• Idempotent = multiple identical requests have the same effect as one request.
• Important for reliability and safe retries.
• HTTP Methods:
• GET, PUT, DELETE → Idempotent.
• POST → Not idempotent (creates new resource each time).

• 2xx Success → 200 (OK), 201 (Created).
• 4xx Client Errors → 400 (Bad Request), 401 (Unauthorized), 404 (Not Found).
• 5xx Server Errors → 500 (Internal Server Error), 503 (Service Unavailable).
• Error responses should include structured messages:

"status": 400,

"error": "Invalid Data",

"details": "Email is required"

Review the concept and prepare a concise verbal explanation with a real project example.

• Ensures correctness, reliability, performance, and security of APIs.
• Postman → Manual and automated API testing, environment variables, collections.
• Swagger (OpenAPI) → Live documentation, mock servers, auto-generated client

SDKs.

• Automates QA process and reduces bugs in production.

🔹 API Scalability & Performance – Interview Q&A

• Horizontal scaling → Add more servers/containers.
• Load balancing across multiple instances.
• Database optimization (indexes, partitioning, read replicas).
• Caching at server, client, and CDN levels.
• Use asynchronous processing for long-running tasks.
• Apply rate limiting and throttling to prevent abuse.
• Adopt microservices architecture for modular scaling.

• Use a load balancer (NGINX, HAProxy, AWS ELB, Azure Front Door).
• Distribute traffic across multiple instances to avoid bottlenecks.
• Support round-robin, least connections, or IP hash strategies.
• Enable health checks to route traffic only to healthy instances.
• Combine with auto-scaling for dynamic traffic management.

• Reduce payload size (use JSON instead of XML, compress responses).
• Implement pagination for large datasets.
• Apply caching at multiple levels.
• Use async I/O (non-blocking calls).
• Minimize database calls (batch queries, stored procedures).
• Enable GZIP compression on responses.
• Profile and monitor using APM tools (New Relic, Application Insights).

Caching is storing frequently used data temporarily to reduce server load and improve

response time.

Implementation methods:

• HTTP caching headers (Cache-Control, ETag, Expires).
• Reverse proxies (Varnish, NGINX).
• In-memory stores (Redis, Memcached).
• Client-side caching using 304 Not Modified.

• Client-side caching → Reduces server calls, but may serve stale data.
• Server-side caching → Faster responses, but increases memory usage.
• Proxy caching/CDN → Global scalability, but harder cache invalidation.
• Database caching (Redis) → Faster queries, but adds complexity and consistency

issues.

• Content negotiation allows clients to specify desired response format.
• Uses HTTP headers:
• Accept: application/json → Request JSON.
• Accept: application/xml → Request XML.
• The server returns response in requested format (if supported).

👉 Example in ASP.NET Core: Add XML formatter with

services.AddControllers()

.AddXmlSerializerFormatters();

• Add query parameters:
• Filtering: /products?category=shoes&brand=nike
• Sorting: /products?sort=price_asc
• Searching: /products?search=wireless+headphones
• Use LINQ/SQL queries in backend.
• Ensure query optimization with indexes.
• Implement validation to prevent SQL injection.

• Deploy servers closer to users (geo-distributed hosting).
• Use CDNs for static content.
• Apply connection pooling for databases.
• Reduce number of API calls (batching, GraphQL alternative).
• Use HTTP/2 or gRPC for faster communication.
• Monitor latency with APM tools and optimize bottlenecks.

• A CDN caches and delivers static or semi-static content from edge servers close to

users.

• Reduces latency and improves response times.
• Helps with traffic offloading, reducing load on origin servers.
• Supports DDoS protection and scaling under heavy loads.

👉 Example: Cloudflare, Akamai, AWS CloudFront.

🔹 API Documentation & Tools – Interview Q&A

• Swagger/OpenAPI → Standard for REST API design and documentation.
• Postman → Can generate collections and documentation automatically.
• Redoc → Static documentation from OpenAPI specs.
• RAML → RESTful API Modeling Language.
• Stoplight, Apiary, Docusaurus → Modern documentation and mocking platforms.

• Swagger/OpenAPI is a specification for defining REST APIs.
• Provides machine-readable and human-readable documentation.
• Enables automatic client SDK generation, testing, and validation.
• Improves team collaboration and consistency in API design.

• Contains all endpoints, request/response formats, parameters, headers, and

security details.

• Acts as a contract between client and server.
• Used for auto-generating documentation, client SDKs, and mock servers.

• In ASP.NET Core: Use Swashbuckle package to generate Swagger UI from

controllers and annotations.

services.AddSwaggerGen(c =>

c.SwaggerDoc("v1", new OpenApiInfo { Title = "My API", Version =

"v1" });

});

app.UseSwagger();

app.UseSwaggerUI(c => c.SwaggerEndpoint("/swagger/v1/swagger.json",

"My API v1"));

• Other frameworks (Node.js: swagger-jsdoc, Spring Boot: springdoc-openapi)

also support annotations and automatic documentation.

• RAML (RESTful API Modeling Language) → YAML-based specification for APIs.
• Focuses on design-first API approach.
• Differences with OpenAPI/Swagger:
• RAML is more design-oriented; Swagger is implementation-oriented.
• OpenAPI has better tooling support and community adoption.

• Postman is a GUI tool for testing REST APIs.
• Features:
• Send HTTP requests (GET, POST, PUT, DELETE).
• Automate tests using Postman Collections.
• Generate documentation and mock servers.
• Supports environment variables and CI/CD integration.

🔹 Error Handling & Debugging – Interview Q&A