API Design

Question 1

REST Principles

Answer 1

1. Stateless
   Each request must contain all the information needed to process it. The server does not store session state between requests.
   Why?: Improves scalability since the server does not need to track client state.
   Example:
   ✅ RESTful: Each request has an Authorization token in headers.

2.** Client-Server Architecture **
The client (UI) and server(data) must be independent;
Why?: Increases flexibility; clients and servers can evolve independently.

3. Uniform Interface 🎯
   A consistent way to interact with resources using standard methods (GET, POST, PUT, DELETE).
   Why?: Simplifies API usage and improves interoperability.
   Example:
   ✅ /users/123 → GET (Fetch user), PUT (Update user), DELETE (Remove user).
   ❌ /fetchUser?id=123 (Non-uniform, not RESTful).

4.** Cacheability**
Definition: Responses must define whether they are cacheable to reduce unnecessary requests.
Why?: Boosts performance, reduces server load.

5. Layered System
   The client doesn’t need to know if it’s communicating with the final server or intermediary (load balancer or proxy).
   Why?: Enhances security, scalability, and flexibility.
   Example:
   A gateway (like API Gateway) handles authentication before forwarding the request to the actual API server.
6. Code on Demand (Optional)
   Definition: The server can send executable code (like JavaScript or scripts) to the client to execute.
   Why?: Can extend functionality dynamically
   Example:
   A REST API delivering a JavaScript snippet for A/B testing.

Question 2

What is REST, REST API, RESTful API

Answer 2

REST (Representational State Transfer) is an architectural style for designing networked applications. It relies on stateless communication over HTTP and follows a resource-based approach.

REST : Implementation, may not fully conform, statelessness depends on implementation

RESTful : Strict implementation, stricly stateless

Question 3

What Does Stateless Mean?

Answer 3

A stateless REST API means each request from the client must contain all necessary information for the server to process it.

The server does not store session state between requests.
Each request is independent, and no previous request affects the current one.
Authentication, user details, and request context (pagination details, filters, and preferences)must be sent every time.

Question 4

Why is Statelessness Important?

Answer 4

Benefits of Stateless APIs
✅ Scalability – Easy to scale horizontally (add more servers) since no session data is stored on a specific server.
✅ Reliability – No risk of session data loss if a server crashes.
✅ Performance – No need for expensive session lookups in memory or DB.
✅ Cacheable – Stateless APIs work well with caching (ETag, Cache-Control).
✅ Simplifies Failover & Load Balancing – Any request can go to any server.

Question 5

[ApiController]

Answer 5

Automatic 400 bad request if model state, input is invalid.
Automatic detection of FromBody FromQuery
Less code for validation and binding
Auto documentation hints

Question 6

Why Some APIs Might Not Be Stateless?

Answer 6

Complex workflows – Some applications need multi-step interactions (e.g., shopping carts).
Performance Optimization – Maintaining state in-memory reduces DB calls.
User Sessions – Some applications store user sessions for authentication.
Web Applications Needing Session State – e.g., a dashboard tracking user sessions.
Long-Lived Workflows – Workflows requiring persistent state (e.g., video uploads).

🔹 Tradeoff? → Use tokens (JWT) . If state must be stored, use Redis or DB, not in-memory storage. Else If the server restarts, data is lost.
🔹 Solution? → Use Redis, DB, or stateful APIs selectively while keeping other services stateless.

Question 7

What are stateless authentication

Answer 7

JWT Token : elf-contained, containing user info in the token payload
OAuth
API Keys

Do not use session or cookies because server will then have to track and store

Question 8

What Does Client-Server Architecture Mean?

Answer 8

Client-Server is a separation of concerns between the client (frontend, mobile app) and server (backend, API).

The client sends requests to the server and only handles UI/UX and interactions.
The server processes business logic, authentication, and data storage.

Question 9

What happens if Violate Client Server Architecture?

Answer 9

❌ Tightly Coupled Systems – If frontend logic is hardcoded into the backend, changes require full redeployment.
❌ Business Logic on the Client – Leads to security risks, as logic can be manipulated by users.

🔹 Tradeoff? → Keep UI and business logic separate, use APIs for communication.

Question 10

Why is Client-Server Separation Important?

Answer 10

✅ Scalability – Servers can be upgraded independently of clients.
✅ Flexibility – Clients (web, mobile, desktop) can evolve separately from backend APIs.
✅ Security – Sensitive logic (authentication, database) is kept on the server.
✅ Reusability – Same API can be used by multiple frontends (React, iOS, Android).
✅ Performance Optimization – Clients handle UI rendering, reducing backend load.

Question 11

What is Layered Architecture?

Answer 11

Layered Architecture in REST enforces a hierarchical structure where components are organized in layers, each performing a specific role.

Layers are independent and interact only with adjacent layers.
Clients do not need to know how the backend is structured.
Security, caching, and load balancing can be added without affecting the client.

Question 11

How to Implement Client-Server Separation Correctly?

Answer 11

The Client Should Only Handle UI/UX
The client should not contain business logic (e.g., pricing calculations).
The backend should perform validations, authentication, and processing.

The Server Should Not Manage UI Logic
API should return raw data, not UI-specific formats (like error messages).
UI elements (e.g., dropdown options) should be handled by the frontend.

Use API Gateways for Cross-Platform Support
A single API should support multiple clients (mobile, web, IoT).
API Gateway can handle versioning, rate limiting, authentication.

Don’t Overloadin the Server with UI-Specific Endpoints. Return all necessary data in one request.

Don’t Hardcode API Calls in Frontend

Secure the Client-Server Communication

Question 12

Why is Layered Architecture Important?

Answer 12

✅ Scalability – Each layer can be scaled independently.
✅ Security – Sensitive data processing happens in deeper layers, not exposed to clients.
✅ Flexibility – API Gateway can be modified without affecting backend logic.
✅ Maintainability – Changes in one layer do not require modifications in others.
✅ Extensibility – Easy to introduce caching, logging, security layers.

Question 13

How to Implement Layered Architecture Correctly?

Answer 13

Use an API Gateway for Routing, Security, and Load Balancing. API Gateway acts as a single entry point for all requests.
✅ Good Approach: Manages authentication, rate limiting, logging, and security. Reduces direct exposure of backend services.

❌ Bad Example (Clients Accessing Microservices Directly)
GET /inventory/orders/12345 // Direct access
✅ Good Example (Using API Gateway)
GET /orders/12345 // Routed through API Gateway

Separate Business Logic from API Controllers
Controller Layer: Handles API requests.
Service Layer: Contains business logic. Caching logic
Repository Layer: Communicates with the database.

Asynchronous processing to improve response times.

Question 14

What is Cacheability in REST APIs?

Answer 14

Cacheability ensures that responses from a REST API can be stored and reused instead of being regenerated for each request. This improves performance, reduces server load, and minimizes latency.

Data freshness and consistency must be maintained to avoid stale data issues.

✅ Lower Bandwidth Usage – Cached responses prevent unnecessary network traffic.
✅ Scalability – Helps scale services to handle more users with fewer resources.

Question 15

When Not to Use Caching?

Answer 15

❌ Highly Dynamic Data – Frequent changes (e.g., stock prices, real-time updates).
❌ Personalized Responses – User-specific data (e.g., user dashboards).
❌ Security-Sensitive Data – API responses containing sensitive info (e.g., authentication tokens).

🔹 Tradeoff? → Balancing freshness and performance is critical.

Question 16

How to Implement Cacheability in REST APIs?

Answer 16

Example of a Cacheable API Response

HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
ETag: “a1b2c3d4”

Question 17

What are ETags

Answer 17

ETags (Entity Tags) help determine if a cached response is still valid.

If content is unchanged, return 304 (Not Modified) instead of 200 (OK).
Reduces bandwidth usage and speeds up requests.

First Request: Server Generates ETag

GET /products/123
HTTP/1.1 200 OK
ETag: “xyz123”
Cache-Control: public, max-age=3600

Subsequent Request with ETag Check

GET /products/123
If-None-Match: “xyz123”

Server Response (If Data Unchanged)

HTTP/1.1 304 Not Modified

Server Response (If Data Changed)

HTTP/1.1 200 OK
ETag: “abc456” // New ETag, updated content

304 response avoids sending duplicate data, saving bandwidth.

Question 18

Cache Layers

Answer 18

Client-Side Cache Browser or mobile app stores API responses. HTTP caching, IndexedDB, Service Workers.

Proxy Cache Caches responses between client and server. Cloudflare, Akamai, Varnish.

Application Cache Stores API results within the API itself. Redis, MemoryCache (C#).

Database Query Cache Caches expensive DB queries. PostgreSQL Query Cache, MySQL Query Cache.

Question 19

Caching Strategy?

Answer 19

Categorize API responses: static, semi-static, dynamic.
Apply caching only where it benefits performance.
Use public for shared data, private for user-specific data.
Implement no-cache for frequently changing data.
Use Layered Caching. Client Cache → CDN Cache → API Cache → Database Cache.

Question 20

What is Uniform Interface in REST APIs?

Answer 20

The Uniform Interface is a fundamental principle of REST APIs that ensures all clients interact with the API in a consistent and predictable way. This improves scalability, interoperability, and ease of use.

🔹 Key Characteristics of a Uniform Interface
✔ Resource-Based URLs – Everything is treated as a resource (/users, /orders).
✔ Standard HTTP Methods – Use GET, POST, PUT, DELETE, PATCH correctly.
✔ Consistent Request & Response Formats – JSON/XML with clear structure.
✔ Stateless Interactions – Each request is independent.
✔ HATEOAS (Hypermedia as the Engine of Application State) – Responses include links for navigation.

Question 21

Why is Uniform Interface Important?

Answer 21

✅ Predictability – Clients know what to expect from the API.
✅ Interoperability – Different clients (web, mobile, IoT) can use the API without special logic.
✅ Decoupling – The client and server evolve independently.
✅ Scalability – Standardized APIs can handle more clients efficiently.

Question 22

Correct way to Uniform Interface

Answer 22

Verbs should be represented by HTTP methods, not in the URL.

Use Consistent Request and Response Formats
Standardized JSON format improves readability and API integration.
Include status codes, messages, and HATEOAS links (optional).

Use HATEOAS for API Discoverability

Question 23

HATEOAS

Answer 23

HATEOAS (Hypermedia as the Engine of Application State) includes navigational links in responses.
​
✅ Example: HATEOAS in User Response
​
{
“id”: 123,
“name”: “John Doe”,
“email”: “john@example.com”,
“links”: {
“self”: “/users/123”,
“orders”: “/users/123/orders”,
“update”: “/users/123/update”
}
}

Question 24

Request Structure in REST APIs

Answer 24

Request Line (Method + URL + Version) Headers (Metadata like authentication, content type) Query Parameters (Filters, pagination, search) Body (Payload for POST, PUT, PATCH) Cookies (Optional, for session/stateful operations)

Question 25

Request Headers

Answer 25

Headers provide metadata about the request. They can define: Content Type (JSON, XML, etc.) Authentication Tokens (JWT, API keys) Caching Directives Client Information (User-Agent, Referrer) Encoding & Compression

Question 26

Query Parameters

Answer 26

Query parameters modify requests dynamically, commonly used for: Filtering (?status=active) Sorting (?sort=name&order=asc) Pagination (?page=1&limit=10) Searching (?q=search-term) Using too many query parameters → leads to long URLs. Use filters in the body for complex queries (POST /search)

Question 27

What Happens If Content-Type is Missing in POST or PUT Requests?

Answer 27

When a POST or PUT request is sent without a Content-Type header, the server might not understand how to parse the request body. The behavior depends on the server's implementation. This often results in an empty request body or a 400 Bad Request error. ASP.NET Core Returns 415 Unsupported Media Type (if body is present). Security Concerns Missing Content-Type increases the risk of attacks like content sniffing vulnerabilities. If a server guesses the content type, it could misinterpret data and open security loopholes. Example Attack Scenario: If a server defaults to text/html, an attacker might inject malicious HTML or JavaScript, leading to XSS attacks.

Question 28

What happens if a GET request has a request body?

Answer 28

According to the HTTP spec, GET requests should not have a body. Many servers ignore the body, while some may return a 400 Bad Request or 411 Length Required. Some APIs (e.g., Elasticsearch) allow a GET request body, but it's not recommended as caching proxies may not handle it correctly. ✅ Best Practice: If you need to send data with GET, use query parameters instead of a body. Use POST or PUT if you're sending a complex payload.

Question 29

What happens if you call DELETE /resource multiple times?

Answer 29

A properly designed DELETE API is idempotent—calling it multiple times should return the same result. First call: Deletes the resource → Returns 200 OK or 204 No Content. Subsequent calls: Since the resource is already deleted, it should return 404 Not Found (or 204 No Content to indicate success without a body). Bad API design: If a DELETE request throws an error when the resource doesn’t exist, it is not idempotent. ✅ Best Practice: Ensure DELETE APIs gracefully handle already-deleted resources. Return 204 No Content or 404 Not Found instead of failing.

Question 31

What happens if a PUT request is sent with partial data?

Answer 31

PUT is meant to replace the entire resource, so missing fields may be set to default values or removed. If partial updates are needed, use PATCH instead of PUT. Some APIs implement merge logic in PUT, but this is against REST principles. ✅ Best Practice: Use PATCH for partial updates. Ensure PUT updates all required fields or rejects incomplete data with 400 Bad Request.

Question 31

Why should you avoid sending sensitive data in query parameters?

Answer 31

Query parameters are logged in browser history, server logs, proxies and referrer headers. They are visible in URLs, making them easy targets for attacks. They are not encrypted in HTTPS URLs, only the request body is encrypted. ✅ Best Practice: Send sensitive data (like passwords, API keys) in the request body or Authorization headers. Use POST /auth instead of GET /auth?user=john&password=123.

Question 31

What happens if a PATCH request sends the entire object instead of just the updated fields?

Answer 31

If the API expects only partial updates, it may apply changes incorrectly. Some APIs merge fields (safe), while others replace existing values with null (dangerous). This can cause data loss if the request doesn't include existing fields. ✅ Best Practice: Follow JSON Patch (application/json-patch+json) standard for clear field updates. Document whether your PATCH API merges fields or replaces them.

Question 32

Can a POST request be idempotent?

Answer 32

POST is not idempotent by default—it creates a new resource each time. However, you can design a POST API to be idempotent using unique request IDs or checking for duplicate records. Example: POST /orders should check if an order already exists before creating it. ✅ Best Practice: Use PUT for updating an existing resource (idempotent). For POST, implement deduplication strategies (idempotency keys, unique constraints).

Question 32

What happens if an API doesn't return an explicit Content-Type in the response?

Answer 32

The client doesn't know how to interpret the response. Browsers may guess the content type, which could lead to security risks (MIME sniffing attacks). Some clients may default to text/html, causing issues when expecting JSON. ✅ Best Practice: Always return a Content-Type header (application/json, application/xml). Set X-Content-Type-Options: nosniff to prevent content guessing.

Question 33

What happens if two concurrent PUT requests update the same resource?

Answer 33

Race condition: The second request may overwrite changes made by the first. The last update "wins", leading to potential data inconsistency. This is known as the Lost Update Problem. ✅ Best Practice: Use optimistic locking (check if the version has changed). Example: The client reads user.version = 1. Sends PUT /users/123 with version = 1. If another request updated it to version = 2, the API rejects the request with 409 Conflict.

Question 34

What happens if a HEAD request returns a response body?

Answer 34

HEAD requests should not return a response body—only headers. If the API accidentally returns a body, some clients may malfunction. Some frameworks strip the body automatically, while others don’t. ✅ Best Practice: Ensure HEAD responses only return headers. Validate responses in API tests (curl -I ).

Question 35

What is the difference between 401 Unauthorized and 403 Forbidden?

Answer 35

401 Unauthorized The request lacks valid authentication (e.g., missing/invalid token). 403 Forbidden The user is authenticated but lacks permission to access the resource.

Question 36

If DELETE returns 200 initially and 404 on subsequent calls, is it still idempotent?

Answer 36

✅ Yes, it's still idempotent. Why? Idempotency means the result is the same after multiple identical requests. The first DELETE removes the resource → returns 200 OK (or 204 No Content). The second DELETE doesn’t change anything (resource is already gone) → returns 404 Not Found. Even though the status code changes, the end result remains unchanged (resource is gone). ❌ Bad Design (Not Idempotent) If the second DELETE throws an error or restores the resource, then it’s not idempotent.

Question 36

X-Content-Type-Options: nosniff – How does it prevent content guessing?

Answer 36

Problem: If Content-Type is missing, browsers try to "guess" the MIME type based on content. This can be exploited by attackers to run malicious scripts. 🔹 How nosniff helps: X-Content-Type-Options: nosniff forces the browser to respect the Content-Type header. If a response has nosniff but no Content-Type, the browser won’t guess and may refuse to load it. ✅ Example Attack (Without nosniff) Server sends application/json, but no X-Content-Type-Options: nosniff. Browser guesses it's text/html and executes JavaScript inside JSON. This leads to XSS (Cross-Site Scripting) attacks. ✅ Correct Defense: Always set both Content-Type and X-Content-Type-Options: nosniff. Even if someone forgets Content-Type, nosniff blocks MIME guessing. 🚀 Takeaway: Content-Type prevents misinterpretation of responses. nosniff acts as a safeguard when Content-Type is missing.

Question 36

What happens if an API only accepts application/json but a client sends text/plain?

Answer 36

The API should reject the request with 415 Unsupported Media Type. If the API does not validate content types, it may try to parse invalid data → parsing errors, crashes, or silent failures. ✅ Best Practice: Strictly enforce Content-Type validation.

Question 37

What happens if a PATCH request contains invalid fields not part of the resource?

Answer 37

Depends on API design: Strict APIs: Return 400 Bad Request for unrecognized fields. Loose APIs: Ignore unknown fields but process valid ones. ✅ Best Practice: Use JSON Schema validation to reject invalid fields.

Question 38

What happens if an API does not return proper CORS headers?

Answer 38

Browsers block cross-origin requests from frontend apps hosted on different domains. Example: API hosted on api.example.com, frontend on app.example.com. If API does not return Access-Control-Allow-Origin: *, the browser blocks the request. ✅ Best Practice: Configure CORS headers (Access-Control-Allow-Origin). Use OPTIONS method to handle preflight requests.

Question 39

What happens if POST is used instead of PUT for updating a resource?

Answer 39

POST creates a new resource, whereas PUT replaces an existing one. If a client mistakenly uses POST to update: It may create duplicate records instead of updating. The API doesn’t guarantee idempotency.

Question 40

What happens if an API does not validate request sizes?

Answer 40

Denial-of-Service (DoS) vulnerability: A client could send huge payloads, consuming memory and CPU. Database performance issues if large requests are stored directly. ✅ Best Practice: Set maximum payload size limits (e.g., 2MB per request). Use 413 Payload Too Large when exceeded.

Question 41

What happens if an API allows file uploads without validation?

Answer 41

Attackers can upload malicious files, including: Executables (.exe, .sh) leading to remote code execution. Scripts (.php, .js) leading to webshell attacks. Large files causing storage exhaustion. ✅ Best Practice: Validate file types (MIME & extension). Set file size limits (e.g., max 10MB). Store files in dedicated storage (e.g., S3, Azure Blob) rather than directly in the API server.

Question 42

What happens if an API does not validate JSON structure in request bodies?

Answer 42

If an API does not validate JSON properly, it may: Accept malformed JSON, leading to undefined behavior. Fail with 500 Internal Server Error instead of 400 Bad Request. Allow SQL Injection or NoSQL Injection attacks. ✅ Best Practice: Always validate JSON schema before processing. Return a 400 Bad Request for invalid JSON.

Question 42

What happens if an API does not set HttpOnly and Secure flags on authentication cookies?

Answer 42

Without HttpOnly, JavaScript can steal cookies via XSS attacks. Without Secure, cookies can be sent over HTTP (not encrypted). Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Strict

Question 43

What happens if an API does not handle large query parameters properly?

Answer 43

Large query parameters may exceed URL length limits (2048 characters in some browsers). Some servers reject long URLs with 414 URI Too Long. Could lead to DoS attacks if unvalidated. ✅ Best Practice: Use POST for large payloads instead of query parameters. Set limits on URL lengths.

Question 43

What happens if an API allows sensitive data in query parameters?

Answer 43

Query parameters are logged in server logs, browser history, and proxies. Can be cached by browsers or proxies. ✅ Best Practice: Use POST with request bodies for sensitive data. Never pass secrets in URLs.

Question 44

What is Stateless Authentication?

Answer 44

Stateless authentication means that: The server does not store user authentication state in any backend storage (DB, Redis, etc.). Each request must contain all the necessary authentication data for validation. **Example: JWT (JSON Web Token)** When a user logs in, the server generates a JWT and sends it to the client. On each request, the client sends the JWT in the Authorization header. The server validates the token without querying a session store. ✅ Why is it Stateless? The server doesn’t need to remember past requests. The authentication state is self-contained in the token. Each request is independent and carries its own authentication info.

Question 45

Why is Stateless Authentication Preferred?

Answer 45

Scalability – No dependency on a session store means easy horizontal scaling (multiple API servers). Performance – No need to query Redis/DB on every request. Fault Tolerance – No single point of failure (session store crash won’t break authentication). Distributed Systems – Works well in multi-server environments and microservices. 📌 When is Session-Based Authentication Used? In traditional web applications where session storage is acceptable. If tokens are too large to send in every request (e.g., when storing lots of permissions).

Question 46

How to prevent brute-force attacks on login?

Answer 46

Implement rate limiting (X failed attempts = lock account). Use CAPTCHAs for repeated failures. Log suspicious login attempts.

Question 47

What happens if an API does not return the correct HTTP status codes?

Answer 47

Breaks error handling on clients. If an API returns 200 OK for errors, clients may misinterpret failures as success. 400 Bad Request → Client errors. 401 Unauthorized → Authentication required. 404 Not Found → Resource not found.

Question 48

What happens if an API does not implement pagination for large datasets?

Answer 48

High database load. Slow API responses. Memory exhaustion on the server.

Question 49

What happens if an API does not handle OPTIONS requests for CORS properly?

Answer 49

Browsers preflight CORS requests with OPTIONS. If the API does not handle OPTIONS, cross-origin requests may fail.

Question 50

What happens if an API does not handle trailing slashes (/) properly?

Answer 50

GET /users/123/ and GET /users/123 might be treated as different endpoints. This can lead to duplicate caching issues or 404 errors. ✅ Best Practice: Use consistent URL structures. Redirect /users/123/ → /users/123 to avoid confusion.

Question 51

If DELETE returns 200 OK on first call and 404 Not Found later, is it idempotent?

Answer 51

Yes. Idempotency means multiple calls have the same effect. After the first delete, the resource is gone.

Question 52

Can an API return 204 No Content for a GET request?

Answer 52

Not recommended. 204 means successful, but no content, which is usually for DELETE or updates. GET should return data or 404 if missing.

Question 53

What happens if a GET request doesn't return Content-Type?

Answer 53

If Content-Type is missing, the client cannot correctly parse the response. Browsers might try to guess using MIME sniffing, which is a security risk. That’s why X-Content-Type-Options: nosniff is used.

Question 54

Why is GET considered safe? Why is GET idempotent?

Answer 54

It does not modify the resource; it only fetches data. Multiple identical GET requests return the same response (assuming no changes on the server).

Question 55

When does a GET request return 304 Not Modified?

Answer 55

When the ETag matches, meaning the client already has the latest version.

Question 56

What is the role of Cache-Control in a GET request?

Answer 56

It instructs how clients/proxies should cache responses (e.g., no-cache, max-age).

Question 57

How does ETag improve GET request efficiency?

Answer 57

It helps reduce bandwidth by allowing conditional requests (If-None-Match).

Question 58

What does If-Modified-Since do in a GET request?

Answer 58

It asks the server to return 304 Not Modified if the resource hasn't changed since a given date.

Question 58

How can GET requests be vulnerable to Cross-Site Request Forgery (CSRF)?

Answer 58

If an API modifies data via GET (which it shouldn't), an attacker can trick users into triggering unwanted actions.

Question 59

Can GET requests be rate-limited?

Answer 59

Yes, APIs can apply rate limits to prevent abuse (e.g., 429 Too Many Requests).

Question 60

GET Request?

Answer 60

GET is meant for data retrieval only → It should never modify state. Safe, Idempotent, Cacheable → But not inherently secure. GET requests are vulnerable to several attacks if misused.

Question 61

Exposing Sensitive Data in URLs

Answer 61

Problem: GET parameters appear in browser history, server logs, referrer headers. ❌ Example: API keys, tokens, passwords leaked in query params. ✅ Solution: Use Authorization headers instead.

Question 62

Open Redirects

Answer 62

(Phishing Risk) ❌ Problem: Attackers can use open redirects to trick users into phishing sites. ✅ Solution: Validate and whitelist redirect URLs. ❌ Bad GET /redirect?url=http://malicious.com ✅ Fix wedDomains.Contains(destination)) { return BadRequest("Invalid Redirect URL"); }

Question 62

Cache Risks

Answer 62

❌ Problem: Cached responses can expose private user data in shared caches. ✅ Solution: Set proper Cache-Control headers. ❌ Bad (Public Caching of User Data) Cache-Control: public, max-age=3600 ✅ Good (Disable Caching for Sensitive Data) Cache-Control: no-store, no-cache, must-revalidate

Question 62

CSRF (Cross-Site Request Forgery)

Answer 62

Problem: If a GET request modifies data, attackers can trick victims into executing it. ✅ Solution: GET should not modify state. If needed, use CSRF protection tokens. ❌ Bad API Design (GET modifies state) GET /transfer?amount=1000&to=xyz ✅ Fix (Use POST + CSRF Protection) POST /transfer { "amount": 1000, "to": "xyz", "csrf_token": "secure123" }

Question 62

Why Are GET Requests Generally Faster? Why is GET usually faster than POST?

Answer 62

✅ Lightweight → No request body, only headers & URL. ✅ Stateless → No session dependency, reducing server load. ✅ Cacheable → Can be served from a local/browser cache or CDN, reducing repeated processing. GET has no request body, is cacheable, and can be served from CDNs.

Question 62

Query Injection Attacks

Answer 62

(SQLi, XSS) ❌ Problem: Poorly validated query params can lead to SQL Injection & XSS. ✅ Solution: Always validate and sanitize input. ❌ Bad (Vulnerable to SQL Injection) GET /search?query=' OR '1'='1 ✅ Fix Use parameterized queries instead of string concatenation. Sanitize query params before processing. var results = db.Query("SELECT * FROM users WHERE name = @name", new { name = search });

Question 62

Why Would Some Browsers Retry a GET Request?

Answer 62

Some browsers automatically retry GET requests due to: 🔹 Network Errors: If a request fails due to timeout, packet loss, or DNS failure, some browsers retry it automatically. 🔹 Page Refresh: A user refreshing a page may trigger another GET request. 🔹 Connection Drops: If the TCP connection resets, some clients resend GET requests. 🔹 Idempotency Assumption: Since GET is idempotent, browsers assume retrying is safe. 👉 Problem? If a GET request unexpectedly modifies data, retries can cause duplicate operations (violating REST principles). ✅ Fix: Never use GET for state-changing operations.

Question 63

How GET Uses Caching for Performance Boost

Answer 63

Caching Mechanisms for GET: 🔹 Browser Cache → Stores GET responses in local storage. 🔹 CDN Cache → Reduces load on origin servers. 🔹 Proxy Cache → Caches responses at the network level. ✅ Key Headers for Performance Cache-Control: public, max-age=3600 ETag: "abc123" 🚀 Effect: Reduces redundant GET requests → Faster load times. ❌ Problem: If sensitive data is cached, it can be accessed later by unauthorized users. ✅ Fix: Use Cache-Control: no-store, private

Question 64

What Affects GET Performance

Answer 64

🔹 DNS Resolution → If not cached, a fresh DNS lookup adds latency. 🔹 TLS Handshake → Secure GET requests (HTTPS) take extra time. 🔹 Header Size Overhead → Large cookies and headers increase request size. 🔹 URL Length Limitations → GET URLs longer than 2048 chars may be truncated or rejected. ✅ Optimization: Use Persistent Connections (Keep-Alive) Minimize Header Size Use HTTP/2 (Multiplexed requests, less latency) 🔹 Load Balancers distribute GET requests across multiple servers. 🔹 CDNs cache GET responses closer to users. 🔹 Compression (Gzip/Brotli) reduces GET response size. ✅ Best Practice: Content-Encoding: gzip 👉 Reduces payload size for faster transfers.

Question 64

What if the GET request is slow?

Answer 64

Possible Causes: High DB load, unoptimized queries. ✅ Solution: Use indexes, caching (Redis), async processing.

Question 64

What if the GET response is too large?

Answer 64

Large JSON payloads increase latency. ✅ Use pagination and gzip compression. Large responses can timeout on slow connections. ✅ Fix: Use pagination, Gzip compression, or smaller payloads.

Question 64

GET Request That Breaks Due to Overloaded Headers

Answer 64

Some browsers limit header size (e.g., 8KB in Chrome). Large headers increase request time & can be rejected. ✅ Fix It Minimize Cookie Size → Don’t store unnecessary data. Use JWT Tokens instead of session cookies. Remove unnecessary custom headers.

Question 65

A GET request works in Postman but fails in a browser. What could be wrong?

Answer 65

Hint: Consider what browsers enforce that Postman doesn’t. 💡 Answer: The server may lack proper CORS headers, so browsers block cross-origin requests. ✅ Fix: Configure Access-Control-Allow-Origin properly on the server.

Question 66

Your GET request contains Unicode characters (?search=你好). Some users report errors, others don’t. Why?

Answer 66

Hint: Consider URL encoding behavior. 💡 Answer: Some servers or proxies may not properly handle non-ASCII characters if URLs aren’t percent-encoded. ✅ Fix: Ensure the frontend properly encodes special characters (你好 → %E4%BD%A0%E5%A5%BD). Check server-side UTF-8 compatibility.

Question 67

A penetration tester uses GET requests with unusual parameters like ?id=1%20OR%201=1. What are they testing?

Answer 67

Hint: What does 1 OR 1=1 do in SQL? 💡 Answer: They’re testing for SQL injection, where unescaped input could allow attackers to modify database queries. ✅ Fix: Use parameterized queries. Never trust user input in database queries.

Question 68

What is CSRF (Cross-Site Request Forgery)?

Answer 68

CSRF is an attack where an authenticated user is tricked into performing an unwanted action on a website without their consent. Exploits browser’s automatic credential sending (cookies, session tokens). Victim logs into a trusted website (e.g., bank.com). The site stores a session token (cookie) in the browser. The victim unknowingly visits a malicious site (e.g., hacker.com). The malicious site sends a hidden request to bank.com Since the user is still logged in, their browser sends the request with authentication cookies. Bank.com processes the transaction, thinking it’s a valid request from the user. Can be used to change passwords, make unauthorized transactions, or delete accounts. Attacker does not need to steal credentials, just needs the victim to be logged in.

Question 69

How to Prevent CSRF?

Answer 69

CSRF Tokens: Unique, random token in forms (). SameSite Cookies: Set-Cookie: sessionid=xyz; HttpOnly; Secure; SameSite=Strict → Prevents cookies from being sent on cross-site requests. Use Authorization Headers Instead of Cookies CSRF mainly affects cookie-based authentication. Using Authorization: Bearer reduces risk.

Question 70

What is CORS (Cross-Origin Resource Sharing)?

Answer 70

CORS is a browser security feature that blocks cross-origin requests by default to prevent unauthorized API access. Enforced by browsers (NOT a server-side security measure). If any site could make API requests to your bank (bank.com), attackers could steal data using JavaScript on malicious websites. CORS prevents this by enforcing a Same-Origin Policy (SOP).

Question 71

How to Allow CORS?

Answer 71

Access-Control-Allow-Origin: https://trusteddomain.com Access-Control-Allow-Methods: GET, POST, OPTIONS This allows trusteddomain.com to access the API. 🚩 CORS Pitfall ❌ Allowing Access-Control-Allow-Origin: * is a major security risk—it permits any site to access your API.

Question 72

Optimistic Locking

Answer 72

Optimistic Locking prevents concurrent updates from overwriting each other in databases. A concurrency control method where requests include a version number or ETag to prevent lost updates. 💡 How Does It Work? Client fetches data (GET /user/123) and receives: { "id": 123, "name": "John", "version": 5 } Client modifies & sends a PUT request: PUT /user/123 Content-Type: application/json If-Match: "5" { "id": 123, "name": "John Doe", "version": 5 } Server checks if version=5 is still valid. If no one else modified the resource, it updates and increments version. If someone else already modified it, the server rejects the request with 409 Conflict. 🔥 Why is HTTP 409 Conflict Useful? Prevents users from overwriting each other’s changes unknowingly. Encourages clients to re-fetch and retry updates. ✅ Best Practice: Use ETag or version numbers to track changes. When receiving a 409 Conflict, re-fetch data before retrying the request.

Question 73

What is idempotency in HTTP?

Answer 73

Idempotency means that making multiple identical requests results in the same outcome as a single request.

Question 74

Why is POST not idempotent?

Answer 74

Because it creates a new resource every time it is called.

Question 75

Why is PUT idempotent?

Answer 75

Because it updates or creates the resource at the same URL, resulting in the same final state no matter how many times it's called.

Question 75

What HTTP status code is returned if a duplicate POST is detected?

Answer 75

409 Conflict.

Question 75

Can PUT create a resource?

Answer 75

Yes, if the client provides the identifier (PUT /users/123), and it remains idempotent.

Question 75

What’s the difference between PUT and PATCH?

Answer 75

PUT replaces the entire resource, while PATCH modifies only specific fields.

Question 76

What happens if PATCH sends the full object instead of just updates?

Answer 76

It can overwrite unintended fields, leading to data loss.

Question 77

Why does PUT require a client-defined identifier?

Answer 77

Because it updates a known resource or creates it at a fixed URL, unlike POST, which generates an ID.

Question 78

Why should you not allow PUT to auto-generate IDs?

Answer 78

Because then each call would create a different resource, violating idempotency.

Question 79

What is the difference between idempotency and safety in HTTP?

Answer 79

Safety means the request doesn’t modify the resource (GET, HEAD, OPTIONS); idempotency means repeated requests have the same result (PUT, DELETE can modify but remain idempotent).

Question 80

How can POST be made idempotent?

Answer 80

By using a unique X-Request-ID and rejecting duplicate submissions.

Question 81

What can violate idempotency in GET requests?

Answer 81

Side effects like logging, analytics, or increasing a counter on every GET request.

Question 82

How can PUT become non-idempotent?

Answer 82

If it generates unique IDs, timestamps, or modifies fields that change on every request.

Question 83

Why is DELETE considered idempotent but can violate idempotency?

Answer 83

Deleting the same resource multiple times should have the same effect (return 404 after the first delete), but if deletion triggers cascading changes (e.g., removing related records), it may not be idempotent. if a DELETE request returns 200 on the first call and 404 on the second, It is still idempotent, as the final state (resource deleted) remains the same.

Question 84

How does using auto-incremented database IDs in PUT violate idempotency?

Answer 84

If a new resource is created every time PUT is called with a missing ID, it creates multiple resources instead of updating the same one.

Question 84

What should be done to make POST idempotent in payment APIs?

Answer 84

Use a request ID and reject duplicate transactions.

Question 84

How does REST API versioning impact idempotency?

Answer 84

Different versions might handle methods differently, making idempotency behavior inconsistent.

Question 85

Why is idempotency crucial in distributed systems?

Answer 85

Network failures, retries, and message duplication require consistent request handling.

Question 86

How does 502 differ from 504?

Answer 86

502 is when the gateway receives an invalid response, while 504 is when it receives no response (timeout).

Question 87

Why use 503 instead of 500?

Answer 87

503 explicitly tells clients the service is unavailable and they should retry later.

Question 88

Can a 500 error expose vulnerabilities?

Answer 88

es, detailed stack traces in 500 errors can expose security flaws.

Question 89

API fails due to DB outage

Answer 89

503 Service Unavailable

Question 90

Why is 204 No Content useful?

Answer 90

Reduces response size for actions that don’t need a body.

Question 91

When to use 202 instead of 201?

Answer 91

202 is used when processing takes time (e.g., background tasks).

Question 92

Can a DELETE request return 200 instead of 204?

Answer 92

Yes, if the server sends back a message confirming deletion.

Question 93

How does 301 differ from 302?

Answer 93

301 is permanent, while 302 is temporary.

Question 94

Why use 304 Not Modified?

Answer 94

Saves bandwidth by letting clients use cached resources.

Question 95

When to use 202 instead of 201?

Answer 95

202 is used when processing takes time (e.g., background tasks).