REST se GraphQL tak ka Safar — Enterprise API Design Blueprint

FIG. 0 — LECTURE 5 & 6 · ORIGINAL SLIDES: M. ABDULLAH

REST se GraphQL tak
ka Safar

Enterprise API Design Blueprint — bachon ke liye asaan Roman Urdu guide. Har topic ki simple wazahat, Pakistan ki apps (Foodpanda, Daraz, Careem, Easypaisa) se real-life misaalein, aur khud try karne wali interactive activities. Neeche scroll karo to page ka rang bhi amber (REST) se teal (GraphQL) ki taraf safar karega — bilkul jaisay lecture khud karta hai.

Shuru Karne Se Pehle: API Kya Hoti Hai?

API ek tarah ka "waiter" hota hai jo do cheezon ke darmiyan paighaam pohnchata hai — customer (app/user) aur kitchen (server/database). Jab aap Foodpanda app kholte hain aur biryani order karte hain, aapka phone ek 'request' Foodpanda ke server ko bhejta hai, server order restaurant tak pohnchata hai, aur phir 'response' mein confirmation wapis aata hai.

📱

Customer
(App/User)

🧑‍💼

Waiter
(API / Server)

🍳

Kitchen
(Database)

ACTIVITY

Q1. Agar app aur server ke darmiyan koi waiter (API) na ho, to kya hoga?▸

App aur server ek dusre ko samajh nahi payenge, kyunke koi rasta hi nahi hoga jis se data ka aadan-pradan ho sake. Order kabhi kitchen tak nahi pohnchega.

Q2. Apni zindagi mein 3 apps sochain jahan aap roz API use karte hain (bina jaante hue).▸

Misaal: WhatsApp (message bhejna), Easypaisa (paisay bhejna), Daraz (order karna) — in sab mein background mein APIs kaam kar rahi hoti hain.

TOPIC 1

Monolithic vs Microservices

Shuru mein websites choti hoti hain to unke liye ek hi bara server kaafi hota hai jo har kaam khud karta hai — isay Monolithic Server kehte hain. Lekin jab company Daraz ya Careem jitni bari ho jaye, to millions log ek sath use karte hain. Ek akela server itna load nahi utha sakta. Isliye company apna system chhote chhote alag "departments" (services) mein taqseem kar deti hai — payment ka apna service, user data ka apna, cache ka apna, wagera. Isay Microservices architecture kehte hain.

REAL-TIME MISAAL

Ek choti tuck shop mein ek hi banda sab kuch karta hai — order lena, paisa lena, samaan dena (Monolithic). Lekin jab wahi dukaan bari ho kar Mall ban jati hai, to har cheez ke liye alag counter hota hai — grocery, billing, delivery. Ye sab mil kar poora mall chalate hain (Microservices), bilkul jaise Careem mein ride booking, payment, aur location tracking alag alag services handle karti hain.

ACTIVITY

Q1. Agar ek chhoti tuck shop khud har cheez sambhalti hai, ye kis type ka system hai?▸

Monolithic — kyunke ek hi jaga par sab kaam ho raha hai.

Q2. Careem app jo payment, location, ride booking alag alag services se use karti hai, wo kis type ka system hai?▸

Microservices — har service apna alag kaam karti hai aur sab mil kar app chalate hain.

Q3. Agar Daraz sirf ek hi monolithic server use kare aur 11.11 sale mein crores log ek sath aa jayen, to kya ho sakta hai?▸

Server overload ho kar crash ho sakta hai — isi wajah se badi companies microservices use karti hain. (Upar wala simulation try karo!)

TOPIC 2

REST Architecture ke 5 Pillars

REST (Representational State Transfer) ek tareeqa hai APIs banane ka, jo 5 buniyadi usoolon (pillars) par khara hota hai. Card par click karo aur restaurant wali misaal dekho:

ACTIVITY

Q1. Foodpanda dobara khol kar login/token dobara dena parta hai — ye kaunsa pillar hai?▸

Statelessness — server ko pichli baar ka pata nahi hota, har baar nayi detail deni parti hai.

Q2. Restaurant ka menu board jo pehle se likha hota hai — ye kis pillar se milta julta hai?▸

Cacheability — pehle se save ki hui information dobara istemal ki ja sakti hai.

Q3. Match karo: (a) Waiter/Cashier/Security alag kaam karte hain (b) Order ticket ka fix format▸

(a) Layered System (b) Uniform Interface

TOPIC 3

Resource Modeling & URI Conventions

Har API endpoint (URL) ka ek structure hota hai. Sab se zaroori usool: URL mein sirf 'nouns' (cheezon ke naam) hone chahiye, verbs (actions) nahi — kyunke HTTP verbs (GET, POST, DELETE) pehle hi action batate hain.

REAL-TIME MISAAL

Jaise ghar ka pata tarteeb se likhte hain — Mulk / Shehar / Mohalla / Ghar Number — bilkul waise hi API URL bhi tarteeb se likha jata hai. Ye tarteeb dekh kar hi pata chal jata hai ke hum kis 'cheez' (resource) ke baare mein baat kar rahe hain.

CLICK KARO HAR HISSE PAR

Kisi hisse par click karke dekho ke uska matlab kya hai.

MINI QUIZ — Sahi URL kaunsa hai?

Task: "User number 5 ko delete karna hai"

ACTIVITY

Q1. Ye URL sahi hai ya ghalat: POST /deleteUser/5 ?▸

Ghalat — kyunke 'deleteUser' ek verb (action) hai. Sahi tareeqa: DELETE /users/5.

Q2. Sahi URL banao 'user number 10 ke orders dekhne' ke liye.▸

GET /users/10/orders

TOPIC 4

HTTP Methods & Idempotency

GET data padhta hai (safe). PUT/DELETE idempotent hain — baar baar karo to result same rehta hai. POST not idempotent hai — baar baar karo to har baar naya result banega.

REAL-TIME MISAAL — Easypaisa Scenario

Agar Easypaisa se payment deduction ki request network fail hone ki wajah se 2 dafa chali jaye, to PUT (idempotent) ensure karega ke balance 2 baar na kate. Lekin agar POST use kiya to balance do dafa kat jayega — isi liye payment jese sensitive kaamon mein idempotency bohat zaroori hai.

POST — Not Idempotent

Button dabao — har click par NAYI cheez cart mein add hogi.

Clicks: 0 → Items: 0

PUT — Idempotent

Jitni baar bhi click karo — result HAMESHA same rehta hai.

🧑

Clicks: 0 → Result: hamesha same picture

ACTIVITY

Q1. 'Add to Cart' 2 baar dabayen aur 2 alag cheezein add ho jayein — konsa method?▸

POST — Not Idempotent, isliye baar baar dabane se har baar naya item add hota hai.

Q2. Profile picture ko 'PUT' se 5 baar update karein, result kya hoga?▸

Result same rahega (wahi ek picture) — kyunke PUT idempotent hai.

Q3. GET request 'Safe' kyun kehlati hai?▸

Kyunke GET sirf data padhti hai, kisi cheez ko change ya modify nahi karti.

TOPIC 5

Status Codes & Consistent Error Responses

Server ek 'Status Code' ke sath jawab deta hai: 2xx Success, 3xx Redirection, 4xx Client Error (aapki ghalti), 5xx Server Error (server ka masla).

REAL-TIME MISAAL

Agar Daraz par item out of stock hai ya ID ghalat hai, 404/400 return karein, 500 nahi. 500 ka matlab aapka code phat gaya hai — jaise dukaan mein na maujood cheez maango to dukaandar kahega 'available nahi hai' (404), lekin agar dukaan hi band ho jaye to alag masla hai (500).

Upar se koi status code chunain →

ACTIVITY

Q1. Daraz par aisi product ID search karein jo exist nahi karti — konsa status code milna chahiye?▸

404 (Not Found) — ye Client Error (4xx) hai.

Q2. Agar Daraz ka server hi down ho jaye, konsa status code aayega?▸

500 (Internal Server Error) — ye Server Error (5xx) hai.

Q3. 200, 404, 500, 301 — in mein 'Success' konsa hai?▸

200 — 2xx range 'Success' ko represent karti hai.

TOPIC 6

Massive Data Payloads — Pagination, Filtering & Sorting

Jab database mein lakhon records hon (Daraz ke 10 million products), sab ek sath bhejna mumkin nahi. Hum teen tareeqay use karte hain: Filtering (sirf category=shoes dikhao), Sorting (price ke hisaab se tarteeb), aur Pagination (ek waqt mein sirf kuch items bhejo).

REAL-TIME MISAAL — Daraz 11.11 Sale

URL parameters (?category=shoes&sort=price_asc&limit=20) database ko batate hain ke data kahan se filter aur truncate karna hai taake mobile app lag na kare. Enterprise standard: bade datasets ke liye Cursor-based pagination behtar hai Offset-based se.

GET /products?limit=4

ACTIVITY

Q1. Agar Daraz apni saari 10 million products ek hi baar mein bhej de to kya hoga?▸

App bohat slow ho jayega ya crash ho sakta hai, aur bohat zyada bandwidth use hogi.

Q2. '?category=shoes' URL parameter kya karta hai?▸

Filtering — sirf shoes category ki products dikhata hai, baaqi chupa deta hai.

Q3. Instagram par scroll karte jana aur naye posts load hote rehna — kis concept ka example hai?▸

Pagination (cursor-based / infinite scroll) — thora thora data load hota hai jese scroll karte hain.

TOPIC 7

API Versioning & HATEOAS

Jab company backend update karti hai, purani apps (v1) achanak toot nahi jani chahiyen. Naya version banaya jata hai (/v2) jabke purana (/v1) bhi kuch waqt chalta rehta hai — Non-Breaking Evolution. HATEOAS mein API response ke andar hi agle mumkin actions ke links diye hote hain.

REAL-TIME MISAAL

Careem backend update karte waqt purani app ko turant band nahi karti. HATEOAS ka matlab hai order tracking response mein khud 'next_page' aur 'cancel_order' jese links diye jate hain — jese receipt mein hi likha ho 'agla step yeh hai'.

Non-Breaking Version Rollout

Active

Not launched

Purani app (v1 par) tab tak chalti rehti hai jab tak log khud update na karein.

HATEOAS — Response mein Khud Links

Neeche links par hover/click karo — server khud bata deta hai agla step kya ho sakta hai.

{ "order_id": "8123", "status": "on_the_way", "_links": { "track": "/orders/8123/track", "cancel_order": "/orders/8123/cancel", "next_page": "/orders?cursor=abc" } }

ACTIVITY

Q1. Backend update ke baad purani app turant kaam karna band kar de — kya problem hogi?▸

Log frustrate honge aur app use nahi kar payenge jab tak update na karein — isi liye Non-Breaking versioning zaroori hai.

Q2. HATEOAS response mein '_links' ke andar 'cancel_order' link kyun diya jata hai?▸

Taake client ko khud URL dhoondhna na pare — server khud bata deta hai agla valid action kya ho sakta hai.

TOPIC 8

Documentation, Contracts & API Gateways

Frontend aur backend team pehle se tay karti hain ke API kaise kaam karegi — Consumer-Driven Contract (jese OpenAPI/Swagger). API Gateway ek 'traffic cop' ki tarah kaam karta hai jo requests receive karta hai, Authentication check karta hai, Rate Limiting lagata hai, aur sahi service ki taraf bhej deta hai.

REAL-TIME MISAAL

Swagger UI aapki API ka 'Menu Card' hai. Bilkul jese building ka security guard (API Gateway) pehle entry check karta hai, phir aapko sahi floor/department ki taraf bhejta hai.

API Gateway — Security Guard Simulation

📨

→

🔐Authenticationwaiting…

→

⏱️Rate Limitingwaiting…

→

🧭Routingwaiting…

→

💳Billing Service

ACTIVITY

Q1. Agar Frontend aur Backend team API design par pehle se agree na karein, to kya masla ho sakta hai?▸

Production mein jaake pata chalega ke dono ki expectations match nahi karti — isliye contract pehle se tay karna zaroori hai.

Q2. API Gateway ke 3 kaam kaunse hain?▸

Authentication handle karna, Rate Limiting lagana, aur sahi service ki taraf Routing karna.

TOPIC 9

API Lifecycle: Deprecation & Sunset Policies

Har API ek lifecycle se guzarti hai: Active → Deprecated (warning) → Sunset (fix date) → End of Life ('410 Gone').

REAL-TIME MISAAL

Bilkul jese 3G/2G network band hone se pehle telecom company mahinon pehle warning bhejti hai — Careem bhi purana API version achanak band nahi karti, pehle 'Deprecation' warning aur 'Sunset' date deti hai taake users app update kar lein.

ACTIVITY

Q1. Agar aapko '410 Gone' error mile, iska matlab kya hai?▸

Iska matlab hai ke ye API version 'End of Life' tak pohanch chuki hai aur permanently band ho chuki hai.

Q2. Company achanak API band karne ki bajaye pehle warning kyun bhejti hai?▸

Taake developers/users ko apni app update karne ka waqt mil jaye, warna unki app achanak kaam karna band kar degi.

LECTURE 6 SHURU — SAFAR AAGE BARHTA HAI

REST ki apni ek badi dilemma hai... GraphQL uska jawab hai.

Ab se page ka accent color amber se teal ki taraf jhukta jayega — jaise hum REST ki duniya se GraphQL ki duniya mein qadam rakh rahe hain.

TOPIC 10 · LECTURE 6

The REST Dilemma — Over-Fetching vs Under-Fetching

Over-Fetching: aapko sirf 2 fields chahiye thi (Name, Image) magar server 50-field wala pura JSON bhej deta hai — bandwidth aur battery waste. Under-Fetching: ek single view banane ke liye multiple alag alag requests karni parein.

REAL-TIME MISAAL

Over-Fetching: 'GET /user' request karne par sirf ek apple (naam) chahiye tha, magar pura crate (50 fields) mil gaya. Under-Fetching: profile page banane ke liye GET /bread, GET /eggs, GET /butter — teen alag dukanon par jana pare ek hi cheez ke liye.

Over-Fetching Simulation

Aapko sirf "naam" chahiye tha...

Under-Fetching Simulation

Ek profile page banane ke liye 3 alag "dukanon" par jana parega.

🍞

GET /breadidle

🥚

GET /eggsidle

🧈

GET /butteridle

ACTIVITY

Q1. Apni kisi app mein socho jahan zaroorat se zyada data load hota ho (over-fetching).▸

Misaal: Ek simple contact list app jo har contact ka poora profile (address, birthday, job, sab kuch) load kare jab sirf naam aur phone number chahiye tha.

Q2. Under-fetching kab hota hai?▸

Jab ek hi screen dikhane ke liye app ko server se multiple alag alag requests bhejni parti hain, kyunke ek request mein poora data nahi milta.

TOPIC 11

Enter GraphQL & The Schema Definition Language (SDL)

GraphQL is problem ka solution hai — ek 'smart' query language jahan client khud batata hai usko exactly kaunse fields chahiye, aur server sirf wahi return karta hai. Iske peeche SDL (Schema Definition Language) hoti hai — ek 'strongly typed contract'.

REAL-TIME MISAAL

GraphQL ek smart waiter ki tarah hai. App khud batati hai usko sirf 2 fields chahiye (name, order_total), aur server exactly wahi return karta hai — jese waiter ko boliye 'sirf chai aur biscuit lana', aur wo pura menu laane ki bajaye sirf wahi 2 cheezein le aaye.

Try Karo: Sirf wo fields chuno jo chahiye

Checkbox tick karo — response sirf wahi return karega, na kam na zyada.

SERVER RESPONSE (LIVE)

{}

ACTIVITY

Q1. GraphQL over-fetching ka masla kaise solve karta hai?▸

Client khud exact fields specify karta hai jo usay chahiye, server sirf wahi bhejta hai — extra data bilkul nahi aata.

Q2. SDL Schema ko 'contract' kyun kaha jata hai?▸

Kyunke ye pehle se define kar deta hai ke kaunse data types available hain aur unka structure kya hoga, jise client aur server dono follow karte hain.

TOPIC 12

GraphQL Core Operations — Queries, Mutations & Subscriptions

Query = data fetch (REST ke GET jese). Mutation = data create/modify/delete (POST/PUT/DELETE jese). Subscription = real-time data (WebSockets jese, jab bhi data change ho, turant push ho jata hai).

REAL-TIME MISAAL — Careem Tracking

Agar Careem rider ki live location map par dekhni hai, to GraphQL 'Subscriptions' use hoti hain jo real-time updates push karti hain — location khud ba khud update hoti rehti hai, refresh ki zaroorat nahi.

ACTIVITY

Q1. Sirf apna order history dekhna hai — konsa operation?▸

Query — kyunke sirf data read (fetch) karna hai.

Q2. Naya order place karna hai — konsa operation?▸

Mutation — kyunke data create/modify ho raha hai.

Q3. Live cricket score jo apne aap update hota rehta hai — kis operation jaisa hai?▸

Subscription — real-time push updates.

TOPIC 13

How GraphQL Works: The Resolvers

GraphQL khud koi naya database nahi hota. 'Resolvers' aise functions hain jo decide karte hain ke query ka kaunsa hissa kis purane database (SQL, MongoDB) ya microservice se aayega, aur usay jor kar ek 'Unified JSON Payload' bana kar frontend ko dete hain.

REAL-TIME MISAAL

Ek hi GraphQL query user data PostgreSQL se, payment data Stripe se, aur session data Redis Cache se le kar ek jagah jama kar sakti hai — jese ek manager teen alag departments (accounts, warehouse, delivery) se information collect kar ke aapko ek hi final report de deta hai.

Resolver Flow Simulation

query { user { name payment session } }

↓

🗄️PostgreSQL
(user data)

💳Stripe
(payment)

⚡Redis
(session)

↓

Unified JSON Payload — waiting…

ACTIVITY

Q1. Resolvers ka kaam kya hota hai?▸

Ye decide karte hain ke data kahan se laana hai aur usay combine kar ke wapis dete hain.

Q2. Kya GraphQL apna khud ka database hota hai?▸

Nahi — GraphQL sirf ek query layer hai jo resolvers ke zariye maujooda databases/services se data laata hai.

TOPIC 14

The Architect's Dilemma — GraphQL Complexity & Trade-offs

GraphQL jaadu nahi hai. Query Complexity: nested query 'friends of friends of friends...' server ka CPU overload kar sakti hai. Caching Problem: sab requests ek hi 'POST /graphql' endpoint par jati hain, isliye standard HTTP/CDN caching kaam nahi karti.

REAL-TIME MISAAL

Jese koi bacha baar baar poochta jaye 'mera dost ka dost ka dost ka dost kaun hai...' aur poochte poochte pura system thak jaye. REST mein har resource ka apna URL hone ki wajah se HTTP caching aasan hai.

Nested Query Attack Simulator

Har click par ek aur "friend" level nest karo — dekho CPU kya karta hai.

{ me { friends { ... } } }

CPU Load: 8% — Nesting Depth: 1

Caching: REST vs GraphQL

REST — har resource ka apna cacheable URL:

GET /products ✓ cached GET /users/5 ✓ cached GET /orders ✓ cached

GraphQL — sab kuch ek hi endpoint se guzarta hai:

POST /graphql ✗ not cached POST /graphql ✗ not cached POST /graphql ✗ not cached

Isi liye GraphQL projects mein Apollo/Relay jese tools cache sambhalne ke liye use hote hain.

ACTIVITY

Q1. GraphQL mein caching mushkil kyun hai?▸

Kyunke sab requests ek hi endpoint (POST /graphql) par jati hain, jabke REST mein har resource ka apna alag URL hota hai jo asani se cache ho sakta hai.

Q2. 'Nested Query Attack' kya hai?▸

Jab koi user jaan bujh kar bohat lambi aur gehri (deeply nested) query bhejta hai taake server ka CPU overload ho jaye aur system slow ya crash ho jaye.

TOPIC 15

Synthesis Matrix: REST vs. GraphQL — Final Decision

Agar public API banani hai to REST best hai. Agar complex frontend hai (jese Netflix) jahan bandwidth bachani hai aur screen size ke mutabiq UI badalta hai, to GraphQL is the winner.

CRITERIA	REST API	GraphQL

Decision Tool — Aap Choose Karo

Upar se koi scenario chunain →

ACTIVITY

Q1. Simple public weather API — REST ya GraphQL?▸

REST — kyunke simple resources ke liye REST behtar hai aur seekhna bhi aasan hai.

Q2. Netflix jesi complex app jahan mobile aur TV ko alag data chahiye — REST ya GraphQL?▸

GraphQL — kyunke har device apni zaroorat ke mutabiq exact data maang sakta hai.

FINAL REVISION QUIZ

Sab 15 Topics ka Test

Pehle khud jawab dene ki koshish karo, phir card par click karke check karo. Har question "Samajh gaya ✓" karne se progress bar barhega.

0 / 12 complete

Monolithic vs Microservices

REST Architecture ke 5 Pillars

Resource Modeling & URI Conventions

HTTP Methods & Idempotency

POST — Not Idempotent

PUT — Idempotent

Status Codes & Consistent Error Responses

Massive Data Payloads — Pagination, Filtering & Sorting

API Versioning & HATEOAS

Non-Breaking Version Rollout

HATEOAS — Response mein Khud Links

Documentation, Contracts & API Gateways

API Gateway — Security Guard Simulation

API Lifecycle: Deprecation & Sunset Policies

REST ki apni ek badi dilemma hai... GraphQL uska jawab hai.

The REST Dilemma — Over-Fetching vs Under-Fetching

Over-Fetching Simulation

Under-Fetching Simulation

Enter GraphQL & The Schema Definition Language (SDL)

Try Karo: Sirf wo fields chuno jo chahiye

GraphQL Core Operations — Queries, Mutations & Subscriptions

How GraphQL Works: The Resolvers

Resolver Flow Simulation

The Architect's Dilemma — GraphQL Complexity & Trade-offs

Nested Query Attack Simulator

Caching: REST vs GraphQL

Synthesis Matrix: REST vs. GraphQL — Final Decision

Decision Tool — Aap Choose Karo

Sab 15 Topics ka Test

Mubarak Ho! Aap ne sab 15 topics revise kar liye.

Lecture 5 and 6