[Web/API] Section 1 — Web / App / API Foundation Memory Pack

1. API basics

API is a structured and controlled way for one software system to communicate with another system or backend functionality.

Do not always think API are just micro services. APIs can exist in:

• monolithic applications
• microservice applications
• mobile apps
• web apps
• IoT platforms
• third-party integrations
• internal backend systems

Memory line:

Modern applications need APIs because web apps, mobile apps, devices, cloud services, internal services, and third-party systems all need to exchange data or trigger actions in a controlled way.

---

2. Web app vs web endpoint vs API vs API endpoint

Term	Meaning
Web application	Complete product/system used by user
Web endpoint	Specific page/action in web app
API	Interface for software communication
API endpoint	Specific API route/action

Example:

Web app: Online shopping platform
Web endpoint: /login
API: Backend interface for app communication
API endpoint: GET /api/orders/123

Memory:

Web app = full product. Endpoint = one route/action. API = interface. API endpoint = one API action.

---

3. Modern request flow

Typical flow:

User → Frontend/UI → API → Backend service → Database → Response → Frontend

The frontend does not directly talk to the database. It sends an API request. The backend validates authentication, authorization, input, executes business logic, reads/writes database if needed, and returns structured data like JSON.

Memory:

Frontend asks, API receives, backend checks, database responds, frontend displays.

---

4. Monolith vs microservices

Type	Meaning
Monolith	One large application/codebase contains many features
Microservices	Many smaller independent services handle separate functions

Example:

Monolith:
One app handles login, orders, payments, reports.

Microservices:
User service, order service, payment service, notification service.

Important:

Microservice is not the API. Microservice is the backend worker. API is how others communicate with it.

Memory:

API = how to ask. Microservice = who does the work.

---

5. API types

API type	Memory
REST	Many endpoints, HTTP methods, usually JSON
SOAP	XML/WSDL, legacy enterprise integrations
GraphQL	One endpoint, queries/mutations in body
gRPC	Fast internal service-to-service communication
WebSocket	Real-time two-way open connection

---

6. HTTP methods

Method	Meaning
GET	Read/fetch data
POST	Submit/create/trigger action
PUT	Replace full object
PATCH	Update part of object
DELETE	Delete object

Examples:

GET /api/orders/123       → read order
POST /api/orders          → create order
PUT /api/users/123        → replace user profile
PATCH /api/users/123      → update one field
DELETE /api/orders/123    → delete order

Important correction:

GET and POST encryption depends on HTTPS, not method.

Memory:

Method tells action. HTTPS gives encryption. Authorization controls permission.

---

7. HTTP status codes

Code	Meaning
200	OK / success
201	Created successfully
301/302	Redirect
400	Bad request / invalid input
401	Not authenticated
403	Authenticated but not authorized
404	Not found
500	Internal server error

Most important:

401 = who are you?
403 = I know who you are, but you are not allowed.

Security angle:

• 200 on another user’s data → possible IDOR/BOLA
• 401 → missing/invalid token
• 403 → permission blocked
• 500 → possible server crash, injection, stack trace, weak error handling
• 301/302 → check redirects/open redirect/auth flow

---

8. Request components

Example:

POST /api/v1/users/123/orders?status=pending
Authorization: Bearer abc123
Content-Type: application/json

{
  "product_id": "555",
  "quantity": 2
}

Breakdown:

Part	Value
Method	POST
Path	/api/v1/users/123/orders
Path parameter	123
Query parameter	status=pending
Headers	Authorization, Content-Type
Body	JSON product/quantity data

Memory:

Path param identifies resource. Query param filters/options. Headers carry metadata/auth. Body submits data.

Security angle:

• Path params → IDOR/BOLA
• Query params → filters, redirects, injection, SSRF
• Headers → auth token, cookies, tenant ID
• Body → mass assignment, business logic abuse, SQLi, hidden fields

---

9. Cookies, sessions, JWT

Server-side session

Browser stores: session_id
Server stores: user_id, role, login state

Memory:

Session = ID in browser, real state on server.

JWT

JWT = header.payload.signature

JWT may contain:

user_id, role, expiry, issuer, audience

Memory:

JWT = claims inside signed token.

Server validates:

• signature
• expiry
• issuer
• audience
• algorithm
• role/scope/claims

Important:

JWT is usually signed, not encrypted. Do not put secrets/passwords inside JWT.

Clean answer:

In server-side session, the browser carries only session ID and server stores user session data. In JWT, the token carries claims like user ID, role, and expiry, and the server validates signature and claims before trusting it.

---

10. Client-side vs server-side validation

Type	Meaning
Client-side validation	Browser/frontend checks input
Server-side validation	Backend enforces real business/security rules

Important:

Client-side validation is for user experience. Server-side validation is for security.

Example:

Product price = 100
Attacker changes price to 0 in Burp
Server must reject and calculate price from backend

Anything coming from the client is untrusted. The server must validate price, quantity, role, ownership, object ID, allowed values, and business rules before processing the request.

Memory:

Never trust client input. Backend is the enforcement point.

---

11. Section 1 golden revision lines

Memorize these:

API = controlled communication with backend functionality.

Web app = full product.
API endpoint = one API route/action.

Frontend does not directly talk to database.
API/backend validates and processes requests.

Monolith = one big app.
Microservices = smaller services talking through APIs.

REST = many endpoints.
GraphQL = one endpoint, many queries/mutations.
WebSocket = real-time two-way.
gRPC = fast service-to-service.

GET reads.
POST submits/creates.
PUT replaces.
PATCH partially updates.
DELETE removes.

HTTPS encrypts, not GET/POST.

401 = not authenticated.
403 = authenticated but not authorized.

Path param = resource ID in path.
Query param = filter/options after ?.

Session = state on server.
JWT = claims in signed token.

Client-side validation = UX.
Server-side validation = security.