# REST, GraphQL va WebSocket

> REST, GraphQL va WebSocket qachon ishlatiladi? So'rov-javob va real vaqt aloqasi, endpoint, query, subscription hamda ularni tanlash mezonlari.

Manba: https://learncode.uz/web-dasturlash/rest-graphql-websocket/
Sana: 2026-05-09

![REST endpointlari, GraphQL query va WebSocket real vaqt kanalini taqqoslash](https://learncode.uz/images/web-dasturlash/rest-graphql-websocket-hero.webp)

*REST va GraphQL odatda so'rov-javob uchun, WebSocket esa uzoq ochiq turadigan ikki tomonlama real vaqt aloqasi uchun ishlatiladi.*

[API darsida](https://learncode.uz/web-dasturlash/api-nima) HTTP va JSON orqali dasturlar
gaplashishini ko'rdik. Ammo barcha aloqa bitta shaklda bo'lmaydi. REST,
GraphQL va WebSocket turli muammoni hal qiladi; ulardan biri har vaziyatda
"eng zamonaviy" yoki "eng yaxshi" emas.

## REST — resurslarga yo'naltirilgan API

REST uslubida URL odatda resursni, HTTP metodi esa amal niyatini bildiradi:

```text
GET    /maqolalar
GET    /maqolalar/42
POST   /maqolalar
PATCH  /maqolalar/42
DELETE /maqolalar/42
```

RESTning kuchli tomoni — HTTP semantikasi, holat kodlari, cache va kuzatuv
vositalari bilan tabiiy ishlashi. Oddiy CRUD xizmatlari uchun tushunarli va
keng qo'llab-quvvatlanadi.

Kamchiligi: murakkab ekran bir nechta resursga muhtoj bo'lsa ko'p so'rov
yuborilishi yoki endpoint kerakdan ortiq maydon qaytarishi mumkin. Buni yaxshi
endpoint loyihasi, query parametr va maxsus agregatsiya route'lari bilan ham
hal qilish mumkin.

Bu ikki muammoning o'z nomi bor. **Over-fetching** — server kerakdan ko'p
ma'lumot qaytaradi: mobil ilovaga faqat ism kerak, endpoint esa butun profilni
yuboradi. **Under-fetching** — bitta so'rov yetmaydi: maqolani olgach, muallif
uchun yana so'rov, izohlar uchun yana bittasi kerak bo'ladi.

Sekin mobil tarmoqda o'nta ketma-ket so'rov sezilarli kechikish beradi. Aynan
shu muammo GraphQL paydo bo'lishiga sabab bo'lgan.

### REST'da yaxshi amaliyotlar

Bir necha oddiy qoida REST API'ni ancha qulay qiladi:

- **Ot ishlating, fe'l emas.** `/maqolalar` to'g'ri, `/maqolaOlish` emas —
  amalni HTTP metodi bildiradi.
- **Ko'plik shaklini saqlang.** `/maqolalar/42` — `/maqola/42` emas.
- **Sahifalash qo'shing.** Katta ro'yxatni to'liq qaytarmang: `?limit=20&offset=40`.
- **Filtr va tartibni parametrga oling.** `?holat=faol&tartib=sana`.
- **Versiyani rejalashtiring.** `/v1/maqolalar` keyinchalik buzilmasdan
  o'zgartirish imkonini beradi.

## GraphQL — kerakli maydonni so'rash

GraphQL'da mijoz kerakli ma'lumot shaklini query orqali ifodalaydi. Ko'pincha
bitta HTTP endpoint ishlatiladi:

```graphql
query {
  maqola(id: 42) {
    sarlavha
    muallif { ism }
  }
}
```

Mijoz faqat `sarlavha` va muallif ismini so'radi. Bu murakkab, turli ekranli
mahsulotlarda qulay bo'lishi mumkin. GraphQL schema kuchli hujjat va tip
tizimini beradi.

Lekin serverda query murakkabligi, ruxsat, N+1 so'rovlar, cache va monitoringni
ehtiyotkor boshqarish kerak. Kichik API uchun GraphQL qo'shimcha murakkablik
bo'lishi mumkin.

> **N+1 muammosi nima**
>
> Yuzta maqola ro'yxatini so'radingiz va har biri uchun muallif ismi kerak. Sodda
> yozilgan server avval maqolalar uchun bitta so'rov, keyin **har maqola uchun
> alohida** muallif so'rovi yuboradi — jami 101 ta so'rov. Yechim: barcha kerakli
> muallifni bitta so'rovda olish. GraphQL bu muammoni o'zi hal qilmaydi; buning
> uchun maxsus yechimlar (masalan, DataLoader) ishlatiladi.

GraphQL'da yana bir jiddiy masala bor: **ruxsat**. REST'da har endpoint uchun
tekshiruv yozish tabiiy. GraphQL'da esa mijoz o'zi query tuzadi, ya'ni ruxsat
har **maydon** darajasida tekshirilishi kerak. Foydalanuvchi maqolani ko'ra
olsa ham, muallifning email manzilini ko'rmasligi kerak bo'lishi mumkin.

Cache ham murakkablashadi. REST'da `GET /maqolalar/42` javobini brauzer va CDN
oson saqlaydi. GraphQL'da esa hamma so'rov odatda bitta URL'ga `POST` bo'lib
ketadi — [oddiy HTTP cache](https://learncode.uz/web-dasturlash/cache-cdn-performance) ishlamaydi.

## WebSocket — uzoq ochiq turadigan kanal

Oddiy HTTPda mijoz so'rov yuboradi va server javob qaytaradi. Server yangi
hodisa paydo bo'lganini mijoz so'ramaguncha yubora olmaydi. **WebSocket**
ulanishi esa ochiq turadi va ikki tomon istalgan payt xabar yuborishi mumkin.

Chat, jonli narx, multiplayer o'yin yoki real vaqt monitoringida bu foydali.
Ammo ulanish holatini saqlash, qayta ulanish, xabar tartibi, masshtablash va
autentifikatsiya oddiy HTTP API'dan murakkabroq.

Ulanish `http://` emas, `ws://` (yoki xavfsiz `wss://`) bilan boshlanadi.
Dastlab oddiy HTTP so'rov yuboriladi va u maxsus header orqali WebSocket'ga
"ko'tariladi" (upgrade). Shundan keyin ikkala tomon xabar almashadi.

Amalda uchta masalani oldindan o'ylash kerak:

- **Uzilish.** Mobil tarmoq tez-tez uziladi. Mijoz avtomatik qayta ulanishi va
  uzilgan vaqtdagi xabarlarni qanday olishi rejalashtiriladi.
- **Autentifikatsiya.** Ulanish ochilayotganda kim ulanayotgani tekshiriladi;
  keyin har xabarda qayta tekshirish qiyin bo'ladi.
- **Masshtablash.** Ikki server ishlayotgan bo'lsa, bir serverga ulangan
  foydalanuvchi boshqasidagi xabarni qanday oladi? Odatda o'rtada alohida
  xabar tizimi turadi.

Har doim ham WebSocket kerak emas. Agar ma'lumot **faqat serverdan mijozga**
oqsa — bildirishnoma, jonli hisobot, progress ko'rsatkichi — **Server-Sent
Events** (SSE) yengilroq yechim. U oddiy HTTP ustida ishlaydi, avtomatik qayta
ulanadi va sozlash ancha sodda.

Yana bir yo'l — **polling**: mijoz har necha soniyada so'rov yuboradi. Bu eng
sodda usul va kam o'zgaradigan ma'lumot uchun yetarli bo'lishi mumkin. Real
vaqt talab qilinmasa, murakkab kanal qurish shart emas.

![REST ko'p resurs endpointlari, GraphQL tanlangan maydonlar querysi va WebSocket ikki tomonlama kanal oqimi](https://learncode.uz/images/web-dasturlash/api-aloqa-modellari.webp)

*REST resurs endpointlariga, GraphQL so'ralgan ma'lumot shakliga, WebSocket esa uzluksiz ikki tomonlama xabarlashuvga urg'u beradi.*

## Qaysi holatda qaysi biri

| Talab | Mos boshlanish |
|---|---|
| Oddiy CRUD va public API | REST |
| Turli mijozlar har xil bog'langan maydon so'raydi | GraphQL |
| Chat yoki jonli hodisa kerak | WebSocket |
| Oddiy serverdan hodisa oqimi kerak | Server-Sent Events ham yetishi mumkin |

Bu jadval qat'iy qoida emas. Masalan, ilova asosiy ma'lumot uchun REST,
jonli bildirishnoma uchun WebSocket ishlatishi mumkin.

Tanlashda uch savol yordam beradi. Birinchisi: ma'lumot kim tashabbusi bilan
harakat qiladi — mijoz so'raganda yetarlimi yoki server o'zi xabar berishi
kerakmi? Ikkinchisi: turli ekranlar bir xil ma'lumotni turlicha shaklda
so'raydimi? Uchinchisi: jamoada bu texnologiyani qo'llab-quvvatlaydigan tajriba
bormi?

Ko'p loyihada eng to'g'ri javob — REST'dan boshlash. U eng keng tarqalgan,
hujjatlari ko'p va operatsion jihatdan sodda. Muammo aniq sezilganda, aynan
o'sha qismni boshqa usulga o'tkazish mumkin.

> **Texnologiyani trend uchun tanlamang**
>
> Yangi protokol muammoni avtomatik yechmaydi. Jamoa tajribasi, hosting,
> cache, xavfsizlik, monitoring, mobil tarmoq va loyiha hajmini hisobga oling.
> Oddiy REST endpoint yetadigan joyda murakkab GraphQL qatlamini qo'shish
> yetkazib berish tezligini pasaytirishi mumkin.

![CRUD uchun REST, moslashuvchan query uchun GraphQL va real vaqt uchun WebSocket tanlash mezonlari](https://learncode.uz/images/web-dasturlash/api-tanlash.webp)

*Aloqa texnologiyasi ma'lumot shakli, real vaqt talabi va tizim murakkabligiga qarab tanlanadi.*

> **Bitta mahsulotda uchalasi**
>
> Internet-do'kon katalog va buyurtmalar uchun REST ishlatishi, murakkab admin
> hisobotlarini GraphQL orqali olishi, kuryer joylashuvini esa WebSocket orqali
> jonli yangilashi mumkin. Texnologiyalar raqib emas — ular turli vazifani
> bajaradi.

## API'ni o'zgartirish va versiyalash

API chiqarilgach, uni boshqa dasturlar ishlatadi. Shu paytdan boshlab har
o'zgarish ehtiyotkorlik talab qiladi.

O'zgarishlar ikki turga bo'linadi. **Buzmaydigan** o'zgarish — yangi maydon
yoki yangi ixtiyoriy parametr qo'shish; eski mijozlar ishlashda davom etadi.
**Buzadigan** o'zgarish — maydonni o'chirish, nomini almashtirish yoki turini
o'zgartirish; eski mijozlar ishdan chiqadi.

REST'da buzadigan o'zgarish odatda yangi versiya bilan chiqariladi (`/v2/...`),
eski versiya esa bir muddat ishlab turadi. GraphQL'da esa boshqa yondashuv keng
tarqalgan: maydon `@deprecated` deb belgilanadi, mijozlar asta-sekin yangisiga
o'tadi, keyin eskisi olib tashlanadi.

> **Xato javobini ham shartnoma deb biling**
>
> Ko'p jamoa faqat muvaffaqiyatli javob shaklini hujjatlashtiradi. Amalda mijoz
> xato holatini ham qayta ishlashi kerak. Xato javobining shakli barcha
> endpointlarda bir xil bo'lsin va unda mashina o'qiy oladigan kod hamda odam
> o'qiy oladigan xabar bo'lsin.

## Amaliy mashq

Tanish bo'lgan bitta ilovani tanlang — masalan, ijtimoiy tarmoq yoki
yetkazib berish xizmati. Uning uchta ekranini yozing va har biri uchun qaysi
aloqa usuli mos kelishini belgilang: mahsulot ro'yxati, buyurtma tarixi va
kuryer joylashuvi.

Keyin har tanlov uchun sabab yozing. Nima uchun kuryer joylashuvi uchun polling
yetarli emas? Buyurtma tarixi uchun WebSocket ortiqcha bo'ladimi? Shu savollarga
javob berish texnologiya tanlashni trend emas, talab asosida qilishga o'rgatadi.

## Qisqacha xulosa

- REST resurs, URL va HTTP metodlariga tayanuvchi keng tarqalgan uslub.
- GraphQL mijozga kerakli maydonlar shaklini query bilan so'rash imkonini beradi.
- WebSocket uzoq ochiq turadigan ikki tomonlama real vaqt kanalidir.
- Bitta loyiha turli aloqa usullarini birga ishlatishi mumkin.
- Tanlov trendga emas, muammo, jamoa va operatsion xarajatga bog'liq.

Keyingi darsda [domen, DNS, hosting va deploy](https://learncode.uz/web-dasturlash/domen-dns-hosting)
— xizmat internetda qanday topilishi va joylashtirilishini ko'ramiz.