What is web architecture?

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.

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

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.

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

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

HTTPS (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.

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.