Question 1

What is an API?

Accepted Answer

An Application Programming Interface is the set of endpoints an application exposes so that other applications or frontends can communicate with it, access its data and perform operations without direct access to the database.

Question 2

What goes wrong if you give another application direct database access instead of an API?

Accepted Answer

- The consumer must write complex queries against your schema.
- Critical data can be deleted by accident, breaking every application that shares the database.
- Every new consumer has to learn the internal schema.

An API is a protective layer: it exposes controlled endpoints to read, write or modify data safely.

Question 3

Explain the restaurant analogy for APIs.

Accepted Answer

- Customer places an order: Client application
- Waiter carries it to the kitchen and brings the food back: API
- Kitchen prepares the food: Backend server / database

The customer never enters the kitchen; the frontend never touches the database.

Question 4

What are the two common use cases of APIs?

Accepted Answer

- Inter-application communication: one application reads another's data through its API instead of duplicating the database.
- Frontend-backend communication: the backend exposes APIs that web and mobile frontends consume.

One backend serves many frontends (web, mobile, desktop) through the same API set.

Question 5

REST: data format, why it is the most popular, and how it organizes endpoints.

Accepted Answer

Representational State Transfer. Uses JSON; popular because the structure is simple, lightweight and easy to use, and it handles large data with low volume. Endpoints are organized around resources (/users, /products, /orders) and use the standard HTTP methods GET, POST, PUT, DELETE.

Question 6

SOAP: where is it still found and why was it replaced?

Accepted Answer

Simple Object Access Protocol, XML-based, used for cross-platform communication in legacy and enterprise systems. Drawback: XML is bulky; tags and attributes repeat for every object and array. REST with JSON replaced it in modern systems.

Question 7

GraphQL: what problem does it solve and when would you choose it?

Accepted Answer

A single endpoint where the client sends one query (a query language, somewhat like SQL) describing exactly the data it needs, in JSON. It removes over-fetching (getting more than you need) and under-fetching (needing several REST calls). Choose it when different frontends need different shapes of data from the same backend.

Question 8

gRPC: data format and the situation it is built for.

Accepted Answer

Google Remote Procedure Call, using Protocol Buffers (Protobuf), which are much smaller and faster than JSON or XML. Built for microservice-to-microservice communication where many internal calls happen and low latency is critical.

Question 9

WebSockets: how do they work and why do they matter for real-time features?

Accepted Answer

1. The frontend initiates a request and a persistent channel is established.
2. Once open, both sides can send data at any time.
3. The backend can push messages, notifications and updates without being asked.

- Without WebSockets: Frontend polls: "any new data?" | With WebSockets: Backend pushes when something arrives
- Without WebSockets: Wasteful network calls | With WebSockets: Event-driven, efficient
- Without WebSockets: Higher latency for real-time features | With WebSockets: Instant delivery

Use cases: chat, live notifications, real-time updates.

Question 10

Compare REST, SOAP, GraphQL, gRPC and WebSockets in one table.

Accepted Answer

- REST: Format - JSON. Key trait - Resource URLs + HTTP methods. Best for - Most modern client-server APIs.
- SOAP: Format - XML. Key trait - Strict, verbose. Best for - Legacy enterprise, cross-platform.
- GraphQL: Format - JSON. Key trait - Single endpoint, client picks fields. Best for - Frontends with varying data needs.
- gRPC: Format - Protobuf. Key trait - Tiny payload, very fast. Best for - Internal microservice calls.
- WebSockets: Format - Any. Key trait - Persistent, bidirectional. Best for - Chat, notifications, live data.

Question 11

Which value types can JSON hold?

Accepted Answer

String, number, boolean, null, nested object and array, structured as key-value pairs:

{ "name": "Akshay", "age": 29, "active": true, "address": null,
  "profile": { "city": "Delhi" }, "skills": ["Java", "Python"] }

Question 12

What is the anatomy of a REST endpoint?

Accepted Answer

Endpoint = HTTP method + path. The method says what operation to perform; the path says which resource. Example: GET /users.

Question 13

List the common HTTP methods with an example path and purpose.

Accepted Answer

- GET: Path - /users. Purpose - Retrieve all users.
- GET: Path - /users/{id}. Purpose - Retrieve one user by ID.
- POST: Path - /users. Purpose - Create a user (data in body).
- PUT: Path - /users/{id}. Purpose - Replace the entire record.
- PATCH: Path - /users/{id}. Purpose - Update specific fields.
- DELETE: Path - /users/{id}. Purpose - Delete a user.

Question 14

What are the four components of a request?

Accepted Answer

1. Method: what action to perform on the resource.
2. Path (URL): which resource, e.g. /users, /products, /orders.
3. Headers: metadata about the request, e.g. Content-Type: application/json tells the server the body is JSON.
4. Body: the actual data being sent; used with POST, PUT and PATCH.

Question 15

PUT vs PATCH: show why the wrong choice loses data.

Accepted Answer

PUT replaces the entire resource; any field missing from the body becomes null or default. PATCH updates only the fields you send.

// Original
{ "id": 1, "name": "Muskan", "username": "muskan", "age": 20 }

// PUT with body { "username": "muskan_new" }  → other fields lost
{ "id": 1, "name": null, "username": "muskan_new", "age": null }

// PATCH with body { "username": "muskan_new" } → only username changes
{ "id": 1, "name": "Muskan", "username": "muskan_new", "age": 20 }

Use PUT to replace a whole resource, PATCH to modify specific fields.

Question 16

Nested routes vs filtering with query parameters: when do you use which?

Accepted Answer

- /users: Methods - GET, POST. Purpose - List or create users.
- /users/{id}: Methods - GET, PUT, PATCH, DELETE. Purpose - Operate on one user.
- /blogs/{id}/comments: Methods - GET. Purpose - All comments on a blog.
- /users/{id}/comments: Methods - GET. Purpose - All comments by a user.
- /comments/{id}: Methods - PATCH, DELETE. Purpose - Update or delete one comment.

Nest when there is a clear, direct parent-child relationship (/blogs/{id}/comments). Filter with query parameters for complex relationships, pagination or multi-criteria lookups (/comments?post_id=123).

Question 17

What are the three ways to pass data to an endpoint, and which one is safe for secrets?

Accepted Answer

- Path parameter: Use case - IDs, slugs, unique identifiers. Visibility - Exposed in URL. Example - /users/42.
- Query parameter: Use case - Filtering, sorting, pagination. Visibility - Exposed in URL. Example - /users?age=20&sort=name.
- Request body: Use case - Sensitive or complex data. Visibility - Hidden from URL. Example - { "username": "...", "password": "***" }.

RULE:
Never pass passwords or tokens in path or query parameters; they are visible in the URL, logs and history. Sensitive data goes in the body.

Question 18

What are the two parts of a REST response, and what does the response tell the client?

Accepted Answer

A status code (numeric result) and a response body (the data, in JSON). Together they say whether the request succeeded, whether there was an error, and what data comes back. A well-designed response improves frontend integration, debugging, scalability and user experience.

Question 19

Why do status codes matter to the frontend?

Accepted Answer

They are standardized signals of success, client error, server error or redirection. The frontend uses them to understand what happened and what to do next (show data, ask to log in, show "not found", retry later).

Question 20

List the status codes you should know, grouped by family.

Accepted Answer

- 200: Name - OK. Meaning - Success; body has the requested data.
- 201: Name - Created. Meaning - A new entity was created in the database.
- 204: Name - No Content. Meaning - Success, nothing to return.
- 301: Name - Permanent Redirect. Meaning - Resource moved permanently to a new URL.
- 302: Name - Temporary Redirect. Meaning - Resource temporarily at a different URL.
- 400: Name - Bad Request. Meaning - Invalid or malformed data.
- 401: Name - Unauthorized. Meaning - Authentication required or failed.
- 403: Name - Forbidden. Meaning - Authenticated, but no permission.
- 404: Name - Not Found. Meaning - Resource does not exist.
- 500: Name - Internal Server Error. Meaning - Server-side failure, e.g. database connection down.

2xx success, 3xx redirection, 4xx client error, 5xx server error.

Introduction60/6 done

Fundamentals330/33 done

API Communication240/24 done

Databases360/36 done

Caching200/20 done

Scalability & Data Management350/35 done

Reliability & Operations200/20 done