What if you could share anything instantly with anyone, without lifting a finger?
Why Client-server architecture in Rest API? - Purpose & Use Cases
Imagine you want to share your photos with friends by sending each picture one by one through email or USB drives.
Every time a friend wants a photo, you have to find it, copy it, and send it manually.
This manual sharing is slow and tiring.
You might send the wrong photo or forget to update friends with new pictures.
It's hard to keep track and manage many requests at once.
Client-server architecture lets a central computer (server) store all photos.
Friends (clients) can ask the server for any photo anytime through a simple request.
The server handles all requests quickly and sends the right photo back.
Send photo1.jpg to friend1 via email Send photo2.jpg to friend2 via USB
GET /photos/photo1.jpg from server GET /photos/photo2.jpg from server
This setup makes sharing fast, organized, and scalable, letting many clients get data anytime without confusion.
When you watch videos on YouTube, your device (client) asks YouTube's servers for the video you want.
The server sends the video stream back instantly, so you can watch without waiting.
Manual sharing is slow and error-prone.
Client-server architecture centralizes data and handles many requests smoothly.
It enables fast, reliable, and easy access to shared resources.
Practice
Solution
Step 1: Understand client role
The client is the part of the system that asks for information or services.Step 2: Differentiate from server role
The server responds to client requests by sending data or services.Final Answer:
To request data or services from the server -> Option AQuick Check:
Client requests, server responds [OK]
- Confusing client with server
- Thinking client stores data permanently
- Assuming client controls network hardware
Solution
Step 1: Identify REST API request methods
REST APIs use HTTP methods like GET, POST, PUT, DELETE to communicate.Step 2: Match method to client request
GET is used by clients to request data from servers.Final Answer:
Using an HTTP GET method -> Option BQuick Check:
REST client requests use HTTP methods [OK]
- Confusing SQL with REST API
- Using FTP commands for REST requests
- Thinking local file reads send requests
/users/123 and the user exists?Solution
Step 1: Understand GET request to resource
A GET request to /users/123 asks for user data with ID 123.Step 2: Server response when user exists
If user exists, server sends back user details, usually as JSON.Final Answer:
A JSON object with user details -> Option AQuick Check:
GET existing resource returns data [OK]
- Assuming error if user exists
- Thinking GET causes redirect
- Expecting blank page on success
Solution
Step 1: Understand 404 error meaning
404 means the requested URL or endpoint was not found on the server.Step 2: Link error to cause
If POST returns 404, likely the client sent request to wrong or missing URL.Final Answer:
The server URL endpoint is incorrect or missing -> Option DQuick Check:
404 means URL not found [OK]
- Confusing 404 with method error
- Assuming success on 404
- Thinking data size causes 404
Solution
Step 1: Identify security need
Allowing updates only with valid token means controlling access.Step 2: Apply client-server security concept
Authentication verifies identity; authorization controls permissions on server side.Final Answer:
Authentication and authorization on the server -> Option CQuick Check:
Access control = Authentication + Authorization [OK]
- Thinking client caches control access
- Assuming server sends data without checks
- Believing client can modify database directly
Ready to prove it?
Pass the test and this pattern moves unknown
