Request/response cycle, client-server model, HTTP methods, and how the web works.
Request/response cycle, client-server model, HTTP methods, and how the web works.
Lesson outline
Web architecture is how browsers (clients) and servers talk. The client (browser, app, or device) sends requests; the server processes them and sends responses. This request/response pattern is the basis of the web.
The client doesn't run your business logic-it displays UI and sends user actions. The server runs your code, talks to databases, and returns data or HTML. Understanding this split helps you design APIs and frontends.
Client–server model
Browser, app, device. Sends requests, displays UI.
Runs your code, DB, returns responses.
The client sends requests; the server runs your code and returns responses. This pattern is the basis of the web and every API.
A user types a URL or clicks a link. The browser sends an HTTP request (method, URL, headers, optional body). The server handles it, runs logic, and returns an HTTP response (status code, headers, body).
Status codes tell the client what happened: 200 OK, 201 Created, 404 Not Found, 500 Server Error. Headers carry metadata (content type, caching, cookies). The body is the actual data (HTML, JSON, etc.).
Request / response cycle
Method, URL, headers, optional body
Handles logic, DB, runs your code
Status code, headers, body (HTML/JSON)
Common status codes
GET – Read a resource. Idempotent (same result if called again). No body in request.
POST – Create or submit data. Sends a body in the request (e.g. form data, JSON).
PUT – Replace a resource entirely. Typically includes full representation in the body.
PATCH – Partial update. Send only the fields that change.
DELETE – Remove a resource. No body.
REST APIs use these methods on URLs (resources): GET /users returns a list; POST /users creates one; GET /users/1 returns one; PUT /users/1 updates; DELETE /users/1 removes. Same pattern everywhere.
HTTP methods
GETRead a resource (idempotent)
POSTCreate or submit data
PUTReplace a resource
PATCHPartial update
DELETERemove a resource
The frontend is what runs in the browser: HTML, CSS, JavaScript. It renders UI and calls the backend via HTTP or WebSockets. The backend is your server: it handles requests, talks to a database, and returns data (often JSON).
Single-page apps (SPAs) load once and fetch data via APIs. Server-rendered apps return HTML from the server on each request. Static sites are pre-built files (HTML/CSS/JS) served as-is. All use the same client-server model.
Frontend vs backend
Runs in the browser
Runs on the server
Ways to build the frontend
Load once, fetch data via APIs
Server returns HTML on each request
Pre-built HTML/CSS/JS served as-is
An API (Application Programming Interface) is how clients talk to your server. REST is a style: resources as URLs, HTTP methods for actions, stateless requests. JSON is the usual format for request and response bodies.
API design matters: clear URLs (/users, /users/1), consistent status codes, and versioning (/v1/users). Understanding REST helps you use and build any cloud or on-prem API.
APIs and REST
/users, /users/1, /orders — each resource has a clear path
GET read, POST create, PUT replace, PATCH update, DELETE remove
Request and response bodies in JSON — the standard for APIs
Example REST API
GET/usersReturns list of usersPOST/usersCreates a new userGET/users/1Returns user with id 1PUT/users/1Replaces user 1DELETE/users/1Removes user 1HTTPS (TLS) encrypts traffic so attackers can't read or modify it. Cookies and tokens carry session or auth data. CORS (Cross-Origin Resource Sharing) controls which domains can call your API from the browser.
Same-origin policy limits what a page can do to other origins. APIs use CORS headers to allow trusted frontends. Authentication (who are you?) and authorization (what can you do?) apply to every request.
Basic web security
Encrypts traffic so attackers can't read or modify it. Always use HTTPS in production.
Carry session or auth data. Cookies: set by server, sent with requests. Tokens: often in headers (e.g. Bearer).
Cross-Origin Resource Sharing. Controls which domains can call your API from the browser. Server sends CORS headers.
Browser limits what a page can do to other origins. APIs use CORS to allow trusted frontends.
🔐 Every request: Authentication (who are you?) and authorization (what can you do?).
Request/response, HTTP methods, and APIs are the same in the cloud. Serverless (Lambda, Functions) is still request/response-you just don't manage the server. API gateways and load balancers sit in front of your code.
Whether you build a monolith, microservices, or a static site, understanding web architecture helps you design systems, debug issues, and work with any provider's services.
Web architecture applies everywhere
Still request/response—you just don't manage the server (Lambda, Functions).
TLS encrypts traffic; CORS controls which domains can call your API from the browser.
Same HTTP methods and REST patterns in cloud APIs, gateways, and load balancers.
Related concepts
Explore topics that connect to this one.
Interview prep: 2 resources
Use these to reinforce this concept for interviews.
View all interview resources →Ready to see how this works in the cloud?
Switch to Career Paths for structured paths (e.g. Developer, DevOps) and provider-specific lessons.
View role-based pathsSign in to track your progress and mark lessons complete.
Questions? Discuss in the community or start a thread below.
Join DiscordSign in to start or join a thread.