Loading...
A browser can exchange structured data with a server without becoming the database itself. Follow the request, validation and response boundaries when explaining a web application.
What you'll be able to do
In a request/response model, the client requests a resource or operation and the server returns a response. A WebSocket connection supports persistent full-duplex message exchange, allowing both sides to send messages without starting a separate ordinary request for every update. The standard classroom model runs over TCP, often protected by TLS.
Live notifications and interactive updates can benefit from such a connection. Persistent communication still needs message formats, authentication, error handling and limits. “Full duplex” describes two-way communication capability, not a claim that every message is delivered instantly or that the server can skip validation.
CRUD means create, retrieve, update and delete. AQA’s simplified example maps GET to retrieval/SELECT, POST to creation/INSERT, PUT to updating and DELETE to deletion. These are useful application mappings, not a rule that HTTP methods directly execute SQL.
The server API interprets the request, checks authorisation and validates data before accessing storage. HTTP semantics are broader: PUT requests a target resource’s state be created or replaced and is idempotent in intended effect. Repeating a GET should not be used to trigger a destructive update merely because a URL is easy to call.
JSON represents structured data with objects, arrays and primitive values; XML uses a markup-based tree representation. JSON is often compact for common web payloads, while actual readability, size and parsing cost depend on the data and tooling. Neither format makes untrusted values safe by itself.
A thin client relies more heavily on server processing; a thick client performs more locally and may need more local resources or maintenance. A web application can contain substantial local logic, so “browser” does not automatically mean an entirely thin client. Compare processing location, connectivity dependence and update requirements in the stated design.
{"itemId": 17, "quantity": 2, "available": true}| Application goal | Illustrative HTTP method | Server responsibility |
|---|---|---|
| Retrieve items | GET | Authorise and read |
| Create item | POST | Validate and insert |
| Replace/update resource | PUT | Authorise and apply defined state |
| Delete resource | DELETE | Authorise and remove |
Attempt the task before opening its worked response. Record each change of state, explain the rule used, and check the result against the original requirements. Code examples labelled Python 3 use that language’s conventions; pseudocode states its own assumptions.
Common mistakes to avoid
Key takeaways
Test yourself
Answer a few questions, then review anything you missed.
Start with the quiz above to check the key ideas. You can also choose another topic from the practice library.