REST, GraphQL va WebSocket

API darsida 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:

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:

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.

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 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.

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.

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.

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 — xizmat internetda qanday topilishi va joylashtirilishini ko’ramiz.