REST API bo'yicha eng ko'p beriladigan 37 ta intervyu savoli (va javoblari)

Hiring manager'lar tez-tez beradigan ushbu savollar yordamida navbatdagi REST API intervyungizdan muvaffaqiyatli o'ting.

Distributed system'larda REST API'lar zamonaviy veb-ilovalarning tayanchi hisoblanadi. Single-page app'larni ishlatishdan tortib mobil mijozlar va microservice'larga xizmat ko'rsatishgacha, REST HTTP orqali servislarni loyihalash, taqdim etish va ulardan foydalanishning eng keng tarqalgan yondashuvlaridan biriga aylangan. Shuning uchun ham “REST API'larni bilish” bugungi kunda backend, full-stack va software engineering vakansiyalari tavsiflarida standart talabga aylangan.

Sizdan nafaqat API'larni loyihalash va ulardan foydalanishni, balki REST ortidagi tamoyillarni, scale bo'ladigan tizimlarni qurishning best practice'larini hamda biror narsa noto'g'ri ketganda muammolarni qanday troubleshoot qilishni ham bilishingiz kutiladi. Intervyu oluvchilar bu g'oyalarni tushunishingizni va ularni haqiqiy backend hamda integratsiya muammolarini hal qilishda qo'llay olishingizni ko'rishni xohlaydi.

Ushbu qo'llanmada siz:

REST tushunchalarini asoslardan tortib authentication, versioning va keshlash kabi ilg'or mavzulargacha tushunib olasiz
Amaliy misollar va yo'l qo'ymaslik kerak bo'lgan xatolarni o'z ichiga olgan keng tarqalgan intervyu savollari va javoblari bilan tayyorgarlik ko'rasiz
Flashcard'lar va o'zingizni o'zingiz tekshirish mashqlari orqali o'zingizga bo'lgan ishonchni mustahkamlaysiz
Agar API dizayniga chuqurroq sho'ng'imoqchi bo'lsangiz, scalable servislar qurish ko'nikmalaringizni mustahkamlash uchun to'liq API design roadmap'ini o'rganib chiqishingiz mumkin.

Endi boshlaymiz.

REST API intervyusiga tayyorgarlik

Intervyu savollarini ko'rib chiqishdan oldin, REST API intervyusiga tayyorlanayotganda yodda tutish kerak bo'lgan bir nechta umumiy maslahatlarni keltiramiz.

REST tamoyillari, HTTP metodlari, status code'lar va resource modeling'ni yaxshi tushunishingizga ishonch hosil qiling.
Postman, Swagger kabi platformalardagi coding challenge'lar orqali yoki hatto kichik side project'lar qurib, API'larni loyihalash va ulardan foydalanishni mashq qiling.
Haqiqiy use case'lar uchun API loyihalay olishingizni ko'rsatish maqsadida pagination, rate limiting, authentication (OAuth, JWT) va error handling kabi ilg'or REST tushunchalarini o'rganing.
Agar lavozim muayyan stack bilan bog'liq bo'lsa, API freymvorklari (masalan, Express.js, Spring Boot yoki Django REST Framework) bilan yaxshilab tanishib chiqing va routing, controller'lar hamda middleware qanday ishlashini tushunib oling.
Kompaniyaning mahsulot va xizmatlarini o'rganib chiqing, shunda ular sizdan qanday API muammolarini hal qilishingizni kutishi mumkinligini oldindan yaxshiroq taxmin qila olasiz.

Keng tarqalgan REST API intervyu savollari va javoblarini o'rganish uchun ushbu qo'llanmadan foydalaning. Javoblarni shunchaki yodlab olmang; o'z mulohazalaringiz va dizayn bo'yicha tanlovlaringizni bosqichma-bosqich tushuntirib berishga tayyor bo'ling. Do'stlaringiz bilan mock intervyular o'tkazish tushuntirishlaringizni charxlashga yordam beradi.

Flashcard'lar bilan o'zingizni sinab ko'ring

Siz ushbu flashcard'lardan foydalanishingiz yoki savollarni ro'yxat ko'rinishida ko'rish uchun quyidagi savollar ro'yxati bo'limiga o'tishingiz mumkin.

Savollar ro'yxati

Agar savollarni ro'yxat ko'rinishida ko'rishni afzal ko'rsangiz, ularni quyida topishingiz mumkin.

Boshlang'ich darajadagi REST API intervyu savollari

1. REST'ni qanday ta'riflaysiz?

REST — scalable va ishonchli veb-servislarni loyihalash yoki distributed ilovalarni qurish uchun ishlatiladigan arxitektura uslubi. SOAP (Simple Object Access Protocol) kabi protokollardan farqli o'laroq, u muayyan texnologiyaga bog'lanmagan. Buning o'rniga u server resource'lari bilan o'zaro ishlash uchun GET, POST, PUT, PATCH va DELETE kabi standart HTTP metodlariga tayanadi.

RESTful tizimlar client-server arxitekturasi asosida quriladi: bunda client HTTP so'rov yuboradi, server esa so'ralgan resource'ni yoki bajarilgan amal tafsilotlarini o'z ichiga olgan HTTP javob bilan javob beradi.

RESTful API'larda so'ralgan har bir resource Uniform Resource Identifier (URI) yordamida yagona tarzda identifikatsiya qilinadi. So'rov odatda request line, request header'lar va ixtiyoriy request body'dan iborat bo'ladi, server esa response header'lar va tegishli HTTP status code bilan birga response body'ni qaytaradi.

2. REST'dagi harflar nimani anglatadi?

REST quyidagilarni anglatadi:

R (Representational): resource'ni ifodalovchi JSON yoki XML kabi turli formatlarni bildiradi.
S (State): resource'ning ma'lum bir vaqtdagi ma'lumotlarini ko'rsatadi.
T (Transfer): holatning representation'i client va server o'rtasida HTTP orqali uzatilishini aks ettiradi.

Atamadagi har bir harf ma'lumotlar client va server o'rtasida qanday ifodalanishi, boshqarilishi va uzatilishini tavsiflaydi.

3. REST API'lar nima va ular nima uchun ishlatiladi?

REST API'lar — REST tamoyillariga amal qiladigan, resource'larni URI (Uniform Resource Identifier) orqali taqdim etadigan va mijozlarga (brauzerlar, mobil ilovalar yoki boshqa serverlar kabi) HTTP yordamida backend servislar bilan o'zaro ishlash imkonini beradigan veb-servislar.

Ko'pchilik dasturchilar ularni afzal ko'radi, chunki ular sodda, scalable, stateless va language-agnostic. REST API'lar maxsus protokollarni talab qilmasdan turli tizimlar — mobil, veb yoki microservice'lar — o'rtasida uzluksiz aloqani ta'minlaydi.

4. HTTP va REST o'rtasida qanday farq bor?

HTTP — vebda client'lar va serverlar o'rtasida ma'lumotlar uzatilishini boshqaradigan protokol. U GET, POST, PUT va DELETE kabi request metodlarini, shuningdek header'lar, javob kodlari va xabar tuzilmalarini belgilaydi.

REST esa, o'z navbatida, API'larni loyihalash uchun arxitektura uslubi bo'lib, API'larni resource'lar va amallar atrofida tuzish uchun HTTP'dan foydalanadi. U statelessness, URI'lar orqali resource'larni identifikatsiya qilish va resource'lar ustidagi amallarni ifodalash uchun HTTP request metodlaridan bir xilda foydalanish kabi tamoyillarni qo'llaydi.

Masalan, HTTP sizga GET /users to'g'ri request metodi va URI ekanini aytadi, REST esa “users” resource'ini olishni ifodalash uchun bu so'rovdan qanday foydalanishni belgilaydi.

5. REST API'da “resource” nimani anglatadi?

REST arxitektura pattern'iga (Representational State Transfer) ko'ra, resource'lar REST servislarining markaziy qurilish bloklari hisoblanadi. Resource'larga foydalanuvchilar, mahsulotlar yoki buyurtmalar misol bo'la oladi.

So'ralgan har bir resource /users/123 kabi Uniform Resource Identifier (URI) orqali yagona tarzda identifikatsiya qilinadi. Bu URI REST client'ga REST server'ga HTTP so'rov yuborish va ma'lumotlarni JSON (JavaScript Object Notation) yoki XML kabi formatda o'z ichiga olgan response body bilan HTTP javob olish imkonini beradi.

Resource'lar standart HTTP metodlari yordamida boshqariladi. Masalan, GET ularni oladi, POST yangilarini yaratadi, PUT ularni yangilaydi, DELETE esa o'chiradi. Request body va request header'lar bilan bir qatorda, server muvaffaqiyat yoki muvaffaqiyatsizlikni ko'rsatish uchun response header'lar va tegishli HTTP status code'larni (200 OK, 201 Created, 404 Not Found) qo'shib yuboradi.

6. HTTP so'rov nima va uning asosiy qismlari qaysilar?

HTTP so'rov — REST'da client server bilan aloqa qiladigan usul. U odatda uch qismdan iborat: request line, header'lar va ixtiyoriy body. Bu qismlar birgalikda serverga qaysi resource so'ralayotganini va uni qanday qayta ishlash kerakligini bildiradi.

Request line: bunga HTTP metodi (GET, POST, PUT, DELETE kabi), URI (/users/123 kabi resource'ni identifikatsiya qiladi) va HTTP versiyasi kiradi.
Header'lar: bular serverga HTTP so'rovni tushunishga yordam beradigan qo'shimcha ma'lumotlar, masalan, ma'lumotlar formati (Content-Type: application/json), authentication ma'lumotlari (Authorization: Bearer ) yoki keshlash qoidalari.
Body: bu ixtiyoriy bo'lib, faqat ba'zi HTTP so'rovlarda (POST yoki PUT kabi) mavjud bo'ladi. U client yubormoqchi bo'lgan haqiqiy ma'lumotlarni, odatda JSON formatida olib boradi, masalan, { "name": "Alice" }.

Oddiy qilib aytganda, HTTP so'rov serverga qaysi resource'ni xohlayotganingizni, u bilan nima qilmoqchi ekaningizni va uni to'g'ri qayta ishlash uchun zarur bo'lgan har qanday qo'shimcha ma'lumotni bildiradi.

7. HTTP javob nimalardan iborat?

HTTP javob — client HTTP so'rov yuborgandan keyin server unga qaytaradigan javob. RESTful veb-servislarda odatda uchta asosiy qism bo'ladi:

Birinchisi — status line bo'lib, unga HTTP protokol versiyasi va status code (masalan, 200 OK, 404 Not Found yoki 500 Internal Server Error) kiradi. Bu kodlar error handling uchun juda muhim, chunki ular client'ga so'rov muvaffaqiyatli bo'ldimi, foydalanuvchi avtorizatsiyadan o'tmaganmi yoki server xatolari yuz berdimi — shuni tushunishga yordam beradi.

Ikkinchi qism — response header'lar bo'lib, ular javob haqidagi metadata'ni o'z ichiga oladi. Bu header'lar cache control, content type (JSON yoki XML) yoki authentication talablari kabi xavfsizlik choralarini belgilashi mumkin. Masalan, API'lar faqat ruxsati bor foydalanuvchilar muayyan resource'larga kira olishini ta'minlash uchun header'larda API key'lardan foydalanishi yoki role-based access control'ni qo'llashi mumkin.

Oxirgi qism — response body bo'lib, u qaytarilayotgan haqiqiy dinamik ma'lumotlarni, odatda JSON formatida saqlaydi. Masalan, foydalanuvchi ma'lumotlarini olishda body { "id": 1, "name": "Alice" } ko'rinishidagi ma'lumotni qaytarishi mumkin.

8. REST'da URI nima?

URI — Uniform Resource Identifier so'zlarining qisqartmasi; u REST API'dagi resource'ni yagona tarzda identifikatsiya qiladi. U client'ga resource qayerda joylashganini va unga qanday murojaat qilish mumkinligini bildiradi. Masalan, /api/orders/45 #45 raqamli buyurtmaga ishora qilishi mumkin.

9. Query parametrlari va path parametrlari o'rtasida qanday farq bor?

Path parametrlari resource path'ining bir qismi bo'lib, /users/123 kabi muayyan resource'larni identifikatsiya qilish uchun ishlatiladi. Query parametrlari URI'da "?" belgisidan keyin qo'shiladi va asosan filter qilish, sort qilish yoki pagination uchun ishlatiladi, masalan, /users?age=30&sort=asc.

Qisqasi, path parametrlari “nima”ni olish kerakligini aniqlaydi, query parametrlari esa uni “qanday” olishni belgilaydi.

10. REST'dagi standart yoki asosiy HTTP metodlari qaysilar?

REST'dagi asosiy HTTP metodlari:

GET: ma'lumotlarni olish
POST: yangi resource'lar yaratish
PUT: mavjud resource'larni yangilash yoki almashtirish
PATCH: qisman yangilash
DELETE: resource'larni o'chirish

Bu metodlar to'g'ridan-to'g'ri CRUD amallariga mos keladi, bu esa REST API'larni turli tizimlarda bir xil tarzda loyihalash va ulardan foydalanishni osonlashtiradi.

11. REST API'da statelessness nima?

Statelessness har bir client so'rovi server uni qayta ishlashi uchun zarur bo'lgan barcha ma'lumotlarni o'z ichiga olishi kerakligini va server client'ning session state'ini saqlamasligini anglatadi. Bu REST API'larni scalable qiladi, chunki serverlar so'rovlar o'rtasida client kontekstini eslab qolishi shart emas.

12. Idempotency tushunchasi nima?

Idempotency — necha marta takrorlanishidan qat'i nazar bir xil natija beradigan amalni bildiradi. Bu muhim REST API tushunchasi, chunki u tarmoqdagi muammolar sababli client'lar so'rovlarni retry qilishi mumkin bo'lgan distributed system'larda ishonchlilik, izchillik va xavfsizlikni ta'minlaydi.

REST'da GET, PUT va DELETE idempotent HTTP metodlari hisoblanadi. Dasturchi ularni bir necha marta chaqirsa ham, bu hech qanday qo'shimcha ta'sir ko'rsatmaydi. POST metodi esa idempotent emas, chunki u har safar yangi resource'lar yaratadi.

13. Cross-origin resource sharing (CORS) nima?

CORS — REST servislaridagi resource'lar turli origin'lar o'rtasida qanday ulashilishini boshqaradigan brauzer xavfsizlik mexanizmi. Standart holatda brauzerlar bir domain'dan boshqasiga yuboriladigan so'rovlarni bloklaydi. Serverlar qaysi domain'larga ruxsat berilganini belgilash uchun Access-Control-Allow-Origin kabi response header'lardan foydalanadi. Veb-client'lar boshqa domain'larda joylashgan API'lardan foydalanganda CORS juda muhim.

14. HTTP status code'ning vazifasi nima?

HTTP status code'lar so'rov natijasini bildiradi. Ular so'rov muvaffaqiyatli bo'lganini, client xatosi tufayli muvaffaqiyatsiz bo'lganini yoki server xatosi tufayli muvaffaqiyatsiz bo'lganini ko'rsatadi.

Masalan, 200 OK muvaffaqiyatni anglatadi; agar siz 404 Not Found olsangiz, bu resource mavjud emasligini bildiradi. Agar biror foydalanuvchi 500 Internal Server Error olsa, bu server muammosidan darak beradi. Ular client va server o'rtasidagi aloqani standartlashtiradi.

15. Qaysi HTTP status code'lar muvaffaqiyatni, qaysilari xatolarni bildiradi?

Muvaffaqiyat kodlari 2xx oralig'iga kiradi, masalan, 200 OK, 201 Created va 204 No Content. Client xatolari 4xx oralig'iga kiradi, masalan, 400 Bad Request yoki 401 Unauthorized. Server xatolari 5xx oralig'ida bo'ladi, masalan, 500 Internal Server Error yoki 503 Service Unavailable. Bu toifalar javoblarni tezda tasniflashga yordam beradi.

16. Muvaffaqiyatli patch uchun qaysi HTTP status code mos keladi?

Muvaffaqiyatli PATCH so'rovi uchun server odatda, agar yangilangan resource javobga kiritilgan bo'lsa, 200 OK kodini, body qaytarilmasa, 204 No Content kodini qaytaradi. Ikkala kod ham muvaffaqiyatni bildiradi, lekin client o'zgarishlar tasdig'ini olishi kerak bo'lganda 200 OK afzalroq. Tegishli HTTP status code to'g'ri implementatsiya qilinganini tekshirish muhim.

17. Qachon put, qachon post ishlatish kerak?

RESTful API'larda PUT va POST o'rtasidagi tanlov so'rov ma'lumotlarini va mo'ljallangan resource'ni qanday boshqarmoqchi ekaningizga bog'liq. PUT idempotent, ya'ni bir xil so'rovni bir necha marta yuborish har doim resource'ning bir xil holatiga olib keladi.

Masalan, yangilangan foydalanuvchi ma'lumotlari bilan yuborilgan PUT /users/123 aynan shu foydalanuvchini almashtiradi yoki yangilaydi. Xuddi shu so'rov qayta yuborilsa ham, server uni dublikatlar yaratmasdan qayta ishlaydi.

Boshqa tomondan, POST idempotent emas. U yangi resource'lar yaratish uchun ishlatiladi, ko'pincha POST /users kabi collection endpoint'ida. Request body bir xil so'rov ma'lumotlarini o'z ichiga olgan bo'lsa ham, har bir chaqiruv yangi yozuv yaratadi. Shuning uchun POST metodlari yangi identifikator (masalan, id) generatsiya qilinishini kutadigan amallar uchun eng mos keladi.

Xavfsiz REST API'lar bilan ishlaganda xavfsizlik choralarini ham hisobga olishingiz kerak. PUT va POST so'rovlari maxfiy ma'lumotlarni olib borishi mumkin, shuning uchun maxsus request header'lardan (masalan, token'lar, API key'lar yoki shifrlash tafsilotlari) foydalanish kuchliroq authentication va authorization'ni ta'minlashga yordam beradi.

Tashkilotlar hatto POST yoki PUT amallariga ruxsat berishdan oldin foydalanuvchi rollarini tekshirish kabi o'zlarining xavfsizlik choralarini ham joriy qilishi mumkin.

18. HTTP basic authentication qanday ishlaydi?

HTTP basic authentication'da client credential'larni Authorization header'ida username:password formatidagi Base64'da kodlangan satr sifatida yuboradi. Server ularni decode qiladi va tekshiradi. Credential'larni osongina decode qilish mumkinligi sababli, ular xavfsiz uzatilishini ta'minlash uchun Basic Auth har doim HTTPS orqali ishlatilishi kerak.

19. API'lar uchun TLS'ning vazifasi nima?

TLS (Transport Layer Security) almashinilayotgan ma'lumotlarni shifrlash orqali client va server o'rtasida xavfsiz aloqani ta'minlaydi. Bu ma'lumotlarni yashirincha tinglash va o'zgartirib qo'yishning oldini oladi. REST API'lar uchun TLS juda muhim, chunki authentication token'lari yoki foydalanuvchi ma'lumotlari kabi maxfiy ma'lumotlar ko'pincha tarmoq orqali uzatiladi. Shu sababli har doim oddiy HTTP o'rniga HTTPS'ni afzal ko'rish eng to'g'ri yo'l.

Asoslardan o'tganingizdan so'ng, intervyu oluvchilar odatda taktikasini o'zgartiradi va sizdan real hayotiy vaziyatlarda REST API'larni yaratish, qurish va ulardan foydalanish orqali ko'nikmalaringizni namoyish etishingizni so'raydi. Bunday savollar ko'pincha REST haqidagi nazariy tushunchangiz bilan birga uning turli amaliy holatlarda qo'llanilishini ham tekshiradi, masalan, katta hajmdagi ma'lumotlarni boshqarish yoki API'ning xavfsizligi va maintainability'si haqida qayg'urish. Quyida o'rta darajadagi keng tarqalgan REST API savollaridan ba'zilari keltirilgan.

O'rta darajadagi REST API intervyu savollari

20. REST arxitekturasining constraint'lari qaysilar?

REST arxitekturasining oltita aniq arxitektura constraint'i mavjud:

Client-server separation

Client (frontend) va server (backend) bir-biridan mustaqil, bu ularga alohida rivojlanish imkonini beradi. UI o'zgarishlari API'ni buzmaydi, backend'dagi yaxshilanishlar esa client'ga ta'sir qilmasdan amalga oshirilishi mumkin. Masalan, siz API'ga tegmasdan mobil ilovangiz UI'ini yangilashingiz mumkin.
Statelessness

Har bir API chaqiruvi mustaqil bo'lishi kerak. Server so'rovlar o'rtasida hech qanday ma'lumot saqlamaydi. Buning o'rniga har bir so'rov server uchun zarur bo'lgan hamma narsani — authentication, ma'lumotlar konteksti va hokazolarni — o'zi bilan olib keladi. Bu scaling'ni soddalashtiradi va server murakkabligini kamaytiradi, chunki boshqarilishi kerak bo'lgan session state yo'q.
Cacheable

REST javoblari keshlanishi mumkinmi yoki yo'qmi (va qancha muddatga) — buni aniq ko'rsatishi kerak. Keshlash client'lar yoki oraliq vositachilarga so'nggi ma'lumotlarni qayta-qayta so'rash o'rniga ulardan qayta foydalanish imkonini berib, unumdorlikni oshiradi va server yuklamasini kamaytiradi.
Uniform interface

REST izchil standartlar to'plamidan foydalanadi: resource'larni identifikatsiya qilish uchun URI'lar, ularni boshqarish uchun HTTP request metodlari (GET, POST, PUT, DELETE) va aniq media type'lar (JSON, XML). Bu izchillik API'larni oldindan taxmin qilinadigan va foydalanish osonroq qiladi.
Layered system

API arxitekturasi client bilmagan holda proxy'lar, gateway'lar yoki load balancer'lar kabi qatlamlarni o'z ichiga olishi mumkin. Bu client-server o'zaro ta'sirini o'zgartirmagan holda scalability, xavfsizlik va boshqaruv qulayligini oshirishga yordam beradi.
Code on demand (ixtiyoriy)

Ba'zan server client ishga tushirishi uchun bajariladigan kodni (masalan, JavaScript) yuborishi mumkin. Bu ixtiyoriy bo'lib, client xatti-harakatini moslashuvchan qilish imkonini beradi, lekin an'anaviy REST API'larda keng tarqalmagan.

21. RESTful API'larda versioning qanday amalga oshiriladi?

API versioning zarur, chunki API'lar vaqt o'tishi bilan rivojlanadi. Versioning bo'lmasa, o'zgarishlar kiritilganda, ya'ni yangi field'lar qo'shilganda yoki eski endpoint'lar almashtirilganda mavjud client'lar ishdan chiqishi mumkin. Keng tarqalgan strategiyalar:

URI versioning: versiyani path'ga kiritish, masalan, /api/v1/users. Bu sodda va keng qo'llaniladi.
Header versioning: versiyani request header'larida ko'rsatish, masalan, Accept: application/vnd.myapp.v2+json. Bu URI'ni toza saqlaydi, lekin client tomonda ko'proq sozlashni talab qiladi.
Query parametrlari: versiyani query string'ga qo'shish, masalan, /users?version=2. Bu kamroq uchraydi, lekin ba'zan tezkor test qilish uchun ishlatiladi.

22. REST API'larda backward compatibility qanday saqlanadi?

Backward compatibility API rivojlansa ham eski client'lar ishlashda davom etishi kerakligini anglatadi. REST API'larda backward compatibility'ni saqlash uchun quyidagi strategiyalardan foydalanishingiz mumkin:

Yangi versiyalarni joriy qilayotganda eskilarini ham ishlab turgan holda saqlang (masalan, /v1/ va /v2/).
Field'larni olib tashlash o'rniga yangi ixtiyoriy field'lar qo'shing, shunda eski client'lar ishdan chiqmaydi.
Eski endpoint'larni deprecated deb aniq belgilang va ularni o'chirishdan oldin client'larga o'tish uchun vaqt bering.
Yangi majburiy field'lar qo'shayotganda default qiymatlarni taqdim eting, shunda eski client'lar xatoga uchramaydi.

Masalan, agar /users API'ingizga yangi phoneNumber field'i qo'shilsa, mavjud email yoki name field'larini olib tashlamang. Shunchaki javobga yangi field'ni qo'shing, shunda eski client'lar uni e'tiborsiz qoldira oladi.

23. HATEOAS nima?

HATEOAS — Hypermedia as the Engine of Application State so'zlarining qisqartmasi bo'lib, REST arxitekturasidagi uniform interface constraint'ining bir qismi hisoblanadi. U REST arxitekturasining asosiy, ammo ko'pincha e'tibordan chetda qoladigan constraint'laridan biri. Oddiy qilib aytganda, bu REST server HTTP javobida nafaqat so'ralgan resource'ni, balki client'ga keyingi mumkin bo'lgan harakatlar haqida yo'l ko'rsatadigan hyperlink'larni (yoki hypermedia control'larni) ham taqdim etishi kerakligini anglatadi.

Masalan, agar client GET /users/123 bilan foydalanuvchi tafsilotlarini so'rasa, response body JSON formatidagi foydalanuvchi ma'lumotlaridan tashqari "update": "/users/123", "delete": "/users/123", "orders": "/users/123/orders" kabi havolalarni ham o'z ichiga olishi mumkin. Shu tarzda REST client URI'larni hardcode qilmasdan keyin nima qila olishini dinamik ravishda aniqlay oladi.

HATEOAS'ning haqiqiy foydasi — decoupling. Mavjud client'lar barcha endpoint'larni oldindan bilishi shart emas; ular server taqdim etgan havolalarga ergashishi mumkin. Bu yangi imkoniyatlar qo'shilganda backward compatibility'ni qo'llab-quvvatlaydi, tiklash harakatlariga ishora qilish orqali error handling'ni yaxshilashga yordam beradi va RESTful veb-servislarning client-server arxitekturasi tamoyiliga mos keladi.

24. Qaysi HTTP metodlari safe, qaysilari idempotent?

REST'da safe metodlar server holatini o'zgartirmaydi. Ularga GET, HEAD va OPTIONS kiradi. Masalan, GET /users faqat ma'lumotlarni oladi; u hech narsani o'zgartirmaydi. U har doim side effect'larsiz bir xil natijani qaytargani uchun GET idempotent ham hisoblanadi.

Idempotent metodlar ularni necha marta chaqirishingizdan qat'i nazar bir xil natija beradi. PUT va DELETE idempotent, chunki ularni takrorlash qo'shimcha o'zgarishlarga olib kelmaydi.

Masalan, DELETE /users/5 foydalanuvchini bir marta o'chiradi, uni qayta chaqirish esa boshqa hech qanday ta'sir ko'rsatmaydi. POST na safe, na idempotent; u har doim yangi resource yaratadi. Safe va idempotent metodlarni farqlay olishingiz intervyu oluvchilarga REST dizaynida ishonchlilikni tushunishingizni ko'rsatadi.

25. Mos HTTP status code'larni qanday tanlaysiz?

Status code tanlashda dasturchilar oddiy yo'riqnomalarga amal qilishi kerak.

2xx muvaffaqiyat kodlari: muvaffaqiyatli GET uchun 200 OK, resource qo'shilganda 201 Created va yangilash yoki o'chirish ma'lumot qaytarmasdan muvaffaqiyatli bajarilganda 204 No Content ishlating.
4xx client xatolari: noto'g'ri kiritilgan ma'lumotlar uchun 400 Bad Request, authentication yo'qligi uchun 401 Unauthorized, ruxsatlar yetarli bo'lmaganda 403 Forbidden va mavjud bo'lmagan resource'lar uchun 404 Not Found ishlating.
5xx server xatolari: umumiy nosozliklar uchun 500 Internal Server Error yoki servis ishlamay turganda 503 Service Unavailable ishlating.

Masalan, agar client signup API'siga noto'g'ri email yuborsa, 500 emas, 400 Bad Request qaytaring, chunki bu client'ning aybi.

26. Cache-control header'i ETag'lar bilan qanday ishlaydi?

Keshlash unumdorlik uchun muhim. Cache-Control header'i client'larga javobdan qancha vaqt qayta foydalanish mumkinligini aytadi. Masalan, Cache-Control: max-age=3600 javob bir soat davomida amal qilishini bildiradi.

ETag'lar (Entity Tags) esa resource versiyalari uchun yagona identifikatorlardir. Client'lar resource o'zgarganini tekshirish uchun oxirgi ETag bilan If-None-Match yuborishi mumkin. Agar u o'zgarmagan bo'lsa, server 304 Not Modified bilan javob beradi va bandwidth tejaladi.

Cache-Control header'lari va ETag'lar birgalikda server yuklamasini kamaytiradi va javoblarni tezlashtiradi, bu esa yuqori trafikli API'lar uchun muhim optimizatsiya hisoblanadi.

27. REST API'larda pagination qanday ishlaydi?

Pagination natijalarni kichikroq qismlarga bo'lish orqali katta dataset'larni boshqarishga yordam beradi. Minglab yozuvlarni bir vaqtda qaytarish o'rniga API'lar ularning bir qismini qaytaradi va client'larga ko'proq so'rash imkonini beradi.

Keng tarqalgan usullar:

Page & limit: /users?page=2&limit=20 → 2-sahifadagi 20 ta foydalanuvchini qaytaradi
Offset & limit: /users?offset=40&limit=20 → 40 ta foydalanuvchini o'tkazib yuboradi, so'ng keyingi 20 tasini qaytaradi
Cursor-based: har bir javob bilan “next” cursor token'ini qaytaradi, u keyingi natijalarni olish uchun ishlatiladi

28. Bir nechta bir xil so'rovlarni qanday xavfsiz boshqarasiz?

Takroriy so'rovlar keng tarqalgan, ayniqsa client'lar amallarni retry qiladigan ishonchsiz tarmoqlarda. Takroriy resource yaratilishining oldini olish uchun API'lar idempotency key'lardan foydalanadi.

Masalan, to'lov yaratishda client Idempotency-Key: abc123 kabi yagona key'ni qo'shib yuboradi. Agar xuddi shu so'rov xuddi shu key bilan qayta yuborilsa, server boshqa to'lov yaratish o'rniga xuddi o'sha natijani qaytaradi.

29. Content negotiation nima va u qanday ishlaydi?

Content negotiation client'ga serverga qaysi ma'lumot formatini afzal ko'rishini aytish imkonini beradi. Bu odatda Accept header'i yordamida amalga oshiriladi.

Masalan:

Accept: application/json: server responds in JSON. 
Accept: application/xml: server responds in XML.

Server so'rovga asoslanib qaysi representation'ni qaytarishni hal qiladi. Agar u so'ralgan formatni taqdim eta olmasa, 406 Not Acceptable qaytarishi mumkin.

30. REST GraphQL va gRPC bilan qanday taqqoslanadi?

REST resource'larga asoslangan, keng qo'llaniladi va HTTP bilan ishlatish oson. Biroq u ma'lumotlarni over-fetching yoki under-fetching qilishga olib kelishi mumkin.

GraphQL client'larga bitta query'da faqat o'zlariga kerakli field'larni so'rash moslashuvchanligini beradi. Bu round-trip vaqtini kamaytiradi, lekin ko'proq sozlashni talab qiladi.

gRPC — HTTP/2'ga asoslangan yuqori unumdorlikka ega binary protokol. U streaming'ni qo'llab-quvvatlaydi va microservice'lar uchun juda mos, lekin REST'ga qaraganda inson uchun o'qilishi qiyinroq.

31. REST va SOAP protokollari o'rtasida qanday farq bor?

REST yengil, moslashuvchan va odatda HTTP orqali JSON'dan foydalanadi. Undan foydalanish oson va u zamonaviy veb-ilovalarda keng qo'llaniladi.

SOAP (Simple Object Access Protocol) qat'iyroq, XML'ga tayanadi va WSDL (Web Services Description Language) talab qiladi. Unda o'rnatilgan error handling va xavfsizlik mavjud, lekin REST'ga nisbatan og'ir.

32. REST API'lar uchun TLS'ni qanday majburiy qilasiz?

TLS client va server o'rtasidagi barcha ma'lumotlar shifrlanishini ta'minlaydi. Uni majburiy qilish uchun:

API serverni faqat HTTPS'ni qabul qiladigan qilib sozlang.
Barcha HTTP trafikni HTTPS'ga redirect qiling.
Oddiy HTTP orqali yuborilgan so'rovlarni rad eting.

Bundan tashqari, kuchli TLS versiyalaridan (masalan, TLS 1.2 yoki undan yuqori) foydalaning, sertifikatlarni muntazam rotate qiling va downgrade hujumlarining oldini olish uchun HSTS (HTTP Strict Transport Security) header'larini majburiy qilishni ko'rib chiqing. Xavfsizlikni saqlash uchun sertifikatlarni ishonchli certificate authority'lardan (CA) olish va zaif cipher'lar yoki eskirgan protokollarni (SSLv3 yoki TLS 1.0 kabi) o'chirib qo'yish ham muhim. Bu login credential'lari yoki to'lovlar kabi maxfiy ma'lumotlarni himoya qilish uchun juda zarur.

33. RESTful veb-servislarni implementatsiya qilishda qaysi asosiy jihatlarni hisobga olish kerak?

REST API'larni qurayotganda ularni sodda va ishonchli qiling. Resource'laringiz uchun aniq va izchil path'lardan (URI'lardan) foydalaning va har bir HTTP metodini to'g'ri amalga moslang, ya'ni (GET o'qish uchun, POST qo'shish uchun). Har bir so'rov mustaqil bo'lishi uchun API'ni stateless saqlang.

Amal qilish kerak bo'lgan asosiy amaliyotlar:

Xavfsizlik: resource'larni himoya qilish uchun login yoki token tekshiruvlarini joriy qiling.
Unumdorlik: javoblarni tezlashtirish uchun keshlashdan foydalaning.
Katta hajmdagi ma'lumotlar bilan ishlash: bir vaqtning o'zida haddan tashqari ko'p ma'lumot yubormaslik uchun pagination qo'llang.
Server barqarorligi: haddan tashqari yuklanishning oldini olish uchun limitlar o'rnating yoki monitoring yo'lga qo'ying.

34. Har bir kishi bilishi kerak bo'lgan asosiy REST API tushunchalari qaysilar?

REST bilan ishlaydigan har bir kishi resource'lar URI'lar bilan qanday identifikatsiya qilinishini va ular ustida asosiy HTTP metodlaridan (GET, POST, PUT, DELETE, PATCH) qanday foydalanishni bilishi kerak. Shuningdek, status code'lar va idempotency, statelessness hamda authentication'ni tushunish ham muhim. Boshqa asosiy g'oyalarga tezlikni oshirish uchun keshlash, katta dataset'lar uchun pagination hamda HTTPS (TLS) dan foydalanish va cross-origin so'rovlarni (CORS) boshqarish kabi keng tarqalgan xavfsizlik choralari kiradi.

35. RESTful veb-servislarda webhook'larni qanday implementatsiya qilasiz?

Webhook'lar serverlarga client'larni hodisalar haqida xabardor qilish imkonini beradi va client'larning doimiy ravishda polling qilish zaruratini yo'q qiladi. Implementatsiya qilish uchun client API provayderida callback URL'ni ro'yxatdan o'tkazadi.

Hodisa yuz berganda (masalan, to'lov muvaffaqiyatli o'tganda), server ushbu callback'ga HTTP POST so'rov yuboradi. Client hodisani qayta ishlaydi va javob qaytaradi (masalan, 200 OK).

Masalan, Stripe tizimingizni to'lov hodisalari haqida xabardor qilish uchun webhook'lardan foydalanadi.

36. RESTful veb-servislarda JSON va XML o'rtasidagi farqlar qanday?

RESTful veb-servislarda request va response body'lari uchun eng keng tarqalgan ikkita ma'lumot formati — JSON (JavaScript Object Notation) va XML (eXtensible Markup Language). Ikkalasi ham bir xil maqsadga, ya'ni ma'lumotlarni tuzilmalashga xizmat qiladi, lekin ular uslubi va qo'llanilish holatlari bilan farqlanadi.

JSON yengil, kamroq so'zli va ko'pchilik dasturlash tillarida, ayniqsa JavaScript'da ma'lumotlar tuzilmalari qanday ifodalanishiga juda yaqin. U key-value juftliklari, massivlar va obyektlardan foydalanadi, bu esa uni parse qilishni tezroq, dasturchilar uchun esa u bilan ishlashni osonroq qiladi. Soddaligi va samaradorligi tufayli JSON ko'pchilik zamonaviy REST API'lar uchun standart tanlovga aylangan. Masalan, { "id": 1, "name": "Alice" }.

XML esa, aksincha, ko'proq so'zli bo'lib, ochuvchi/yopuvchi tag'lardan foydalanadi, bu esa payload hajmini oshiradi. Biroq XML ba'zi holatlarda kuchliroq; u attribute'lar, namespace'lar va qat'iy schema'larni (XSD) qo'llab-quvvatlaydi, bu esa uni ma'lumotlar validatsiyasi va murakkab ierarxik tuzilmalar muhim bo'lgan joylarda foydali qiladi. Masalan:

<user id="1"> 
<name>Alice</name> 
</user>

JSON asosan unumdorlik va o'qilishi osonligi uchun afzal ko'riladi, lekin XML enterprise tizimlarda yoki schema validation va hujjatga o'xshash tuzilmalar talab qilinganda hamon qimmatli.

37. Swagger va OpenAPI o'rtasida qanday farq bor?

Swagger va OpenAPI atamalari bir-biri bilan chambarchas bog'liq. Asosiy jihat shundaki, OpenAPI — bu specification, Swagger esa ushbu specification'dan foydalanishingizga yordam beradigan vositalar to'plami.

OpenAPI — REST API'larni tavsiflashning standart usuli. U mavjud endpoint'lar, request metodlari, query parametrlari, authentication turlari va kutilayotgan javoblar kabi tafsilotlarni qanday hujjatlashtirish mumkinligini belgilaydi. Masalan, OpenAPI hujjati (odatda YAML yoki JSON'da yoziladi) odamlar ham, mashinalar ham tushuna oladigan API'ning loyiha chizmasi vazifasini bajaradi. Bu hujjatlar, client SDK'lar va testlarni avtomatik generatsiya qilishni osonlashtiradi.

Swagger esa dastlab ham specification, ham vositalar to'plami sifatida paydo bo'lgan. Keyinchalik specification qismi Linux Foundation'ga topshirildi va OpenAPI Specification (OAS) deb qayta nomlandi. O'shandan beri “Swagger” asosan OpenAPI'ni qo'llab-quvvatlaydigan vositalarni anglatadi. Ularga quyidagilar kiradi:

Swagger Editor — API'larni loyihalash uchun.
Swagger UI — API hujjatlarini brauzerda vizuallashtirish va ular bilan o'zaro ishlash uchun.
Swagger Codegen — server stub'lari yoki client SDK'larni generatsiya qilish uchun.

Qisqasi, OpenAPI — specification (qoidalar va format), Swagger esa ushbu specification'ni implementatsiya qiladigan va u bilan ishlaydigan vositalar to'plami.

Xulosa

REST API tushunchalarini o'rganish — doimiy amaliyot va o'zini o'zi baholashni talab qiladigan uzluksiz jarayon. Yuqoridagi REST API intervyu savollari va javoblarini ko'rib chiqib, siz ko'nikmalaringizni oshirish va keyingi intervyungiz uchun o'zingizga ishonch hosil qilish yo'lida muhim qadam tashladingiz.

Ushbu savollarni taqdim etilgan flashcard'lar bilan mashq qilish va o'zingizni turli ssenariylarda sinab ko'rish orqali tayyorgarligingizdan maksimal darajada foydalaning. HTTP metodlari, status code'lar va authentication kabi tushunchalarni takrorlash uchun muntazam vaqt ajrating, shu bilan birga haqiqiy API integratsiyalarini o'z ichiga olgan loyihalar ustida ishlang. Qaydlar yozish, qisqacha xulosalar tayyorlash yoki hatto REST tamoyillarini boshqa birovga tushuntirish bilimingizni mustahkamlaydi va yanada yaxshilashingiz mumkin bo'lgan jihatlarni ko'rsatib beradi. Bu sizga haqiqiy intervyuda duch keladigan har qanday REST API savollariga o'zingizni qulayroq va tayyorroq his qilishingizga yordam beradi.

Qo'shimcha o'rganish uchun REST'dan tashqari kengroq API dizayni tamoyillari va amaliyotlari haqidagi tushunchangizni kengaytirish maqsadida API design roadmap'ini o'rganib chiqing. Boshqa sohalar bo'yicha kasbiy yo'l va intervyu savollari haqida ko'proq bilish uchun foydali manbalarimizni ko'rib chiqing va boshqa roadmap qo'llanmalarimiz bilan tanishing.