Web Technologies and Client Models

In the client-server model, communication is always initiated by the client (which sends a request) and the server (which sends a response).

HTTP request-response cycle:

Browser (client)        Web server
      │                      │
      │── GET /page.html ───▶│
      │                      │ (server processes request)
      │◀── 200 OK + HTML ───│
      │                      │

HTTP is stateless — each request-response pair is independent. The server holds no record of previous requests from the same client. Cookies and session tokens are used at the application layer to simulate stateful sessions.

CRUD operations map to HTTP methods:

CRUD	HTTP method	Meaning
Create	POST	Submit new data to the server
Read	GET	Retrieve data from the server
Update	PUT / PATCH	Update existing resource
Delete	DELETE	Remove a resource

Standard HTTP is request-response: the client must ask before the server can respond. This creates a problem for real-time applications (live chat, stock prices, multiplayer games) — the client must poll repeatedly.

WebSocket provides a full-duplex persistent TCP connection between a browser and a server.

• The connection is established with an HTTP upgrade request: Upgrade: websocket
• Once established, either side can send data at any time without waiting for a request
• The connection remains open until explicitly closed
• Much lower overhead per message than repeated HTTP requests

Use cases: live chat, real-time dashboards, collaborative editing, multiplayer games, live sports scores.

Comparison:

	HTTP	WebSocket
Initiated by	Client only	Either party
Connection	New connection per request	Persistent single connection
Direction	Half-duplex (request/response)	Full-duplex
Overhead	High (headers each request)	Low after handshake
Use	Standard web pages, APIs	Real-time, live data

REST (Representational State Transfer) is an architectural style for designing web APIs. A RESTful API exposes resources via URLs and uses standard HTTP methods (GET, POST, PUT, DELETE) to act on them.

Example RESTful API:

Method	URL	CRUD operation	Action
GET	/api/users/42	Read	Retrieve user with ID 42
POST	/api/users	Create	Create a new user
PUT	/api/users/42	Update	Replace user 42
PATCH	/api/users/42	Update	Partially update user 42
DELETE	/api/users/42	Delete	Remove user 42

Key REST properties:

• Stateless: each request contains all information needed — no server-side session state
• Resource-oriented: everything is a resource identified by a URL
• Uses standard HTTP methods consistently
• Responses typically return JSON or XML

JSON (JavaScript Object Notation):

{
  "id": 42,
  "name": "Alice",
  "email": "alice@example.com",
  "scores": [95, 87, 91]
}

Lightweight, human-readable, directly usable in JavaScript. Standard format for REST APIs and web data exchange.

XML (eXtensible Markup Language):

<user>
  <id>42</id>
  <name>Alice</name>
  <email>alice@example.com</email>
  <scores>
    <score>95</score>
    <score>87</score>
    <score>91</score>
  </scores>
</user>

More verbose than JSON; supports validation schemas (XSD) and namespaces; used in legacy enterprise systems and document exchange formats.

JSON vs XML:

	JSON	XML
Verbosity	Less verbose	More verbose
Readability	Easy for humans and machines	Readable but bulkier
Schema support	Limited	Strong (XSD)
Typical use	Web APIs, JavaScript apps	Legacy systems, document exchange

Thin client: minimal local processing — the client device relies on a server for most computation and data storage.

• The client mainly handles input/output and display
• Heavy processing (business logic, database queries) runs on the server
• Clients are cheap and simple to maintain — updates happen on the server
• Requires a reliable network connection; no network = no functionality
• Examples: web browser accessing a cloud application, terminal accessing a mainframe

Thick (fat) client: performs significant processing locally — the client handles application logic, and may store data locally.

• Less reliance on server during use — can work offline
• More powerful client hardware required
• Updates must be deployed to each client device
• Examples: desktop applications (Photoshop, Outlook), mobile apps, local IDEs

	Thin client	Thick client
Processing	On server	On client
Storage	Server	Local (possibly + server)
Network dependency	High	Lower
Client hardware cost	Low	Higher
Maintenance	Easy (centralised)	Harder (per-device updates)
Offline capability	Limited	Good

1. Stating WebSocket is a replacement for HTTP

WebSocket is used for real-time, full-duplex communication. It does not replace HTTP — a WebSocket connection is initiated with an HTTP upgrade handshake, and most web communication still uses standard HTTP. They complement each other.

2. Confusing GET and POST

GET retrieves data; parameters are in the URL. POST submits data; parameters are in the request body (not visible in the URL). GET requests are idempotent (repeating them has no side effects); POST creates or updates resources.

3. Claiming thin clients cannot function without a network

Thin clients have very limited offline capability — but the point is not "cannot function at all" — it is that they rely on the server for most processing and storage. A thin client's value proposition is centralised management, not offline use.

4. Confusing REST with a protocol

REST is an architectural style (a set of design constraints), not a protocol. It uses HTTP as its transport protocol. A "RESTful API" follows REST principles; it is not a different protocol from HTTP.