REST — Representational State Transfer, tarqatilgan hypermedia tizimlari uchun Roy Fielding ta’riflagan arxitektura uslubi. REST alohida protokol yoki tayyor API formati emas; u tizim arxitekturasiga qo‘yiladigan cheklovlar majmuasidir. Veb APIlar ko‘pincha HTTP, URL va JSON bilan REST tamoyillarini qo‘llaydi, lekin JSON ishlatgan har qanday HTTP API avtomatik ravishda RESTful bo‘lib qolmaydi.
Resurs va representation
RESTda asosiy obyekt resource hisoblanadi. Resurs foydalanuvchi, maqola, buyurtma yoki boshqa tushuncha bo‘lishi mumkin. U barqaror identifikator, vebda odatda URI orqali aniqlanadi. Client resursning ichki obyektini emas, uning representationini qabul qiladi yoki yuboradi. Representation JSON, XML, HTML yoki boshqa media type ko‘rinishida bo‘lishi mumkin.
Masalan, /articles/42 bitta maqola resursini ifodalaydi. GET /articles/42 uning joriy ko‘rinishini oladi. PUT resurs holatini to‘liq almashtirish, PATCH qisman o‘zgartirish, DELETE esa resursni olib tashlash uchun ishlatilishi mumkin. Metod semantikasi endpoint hujjatida aniq ko‘rsatiladi.
REST cheklovlari
Client–server cheklovi foydalanuvchi interfeysi bilan ma’lumot saqlash mas’uliyatini ajratadi. Stateless talabiga ko‘ra, server har bir so‘rovni tushunish uchun zarur ma’lumotni shu so‘rovning o‘zidan oladi. Server clientning dialog holatini yashirin sessiya sifatida saqlashiga tayanmaydi. Bu talab serverdagi resurs holati umuman bo‘lmaydi degani emas.
Cacheable javob o‘zini cache qilish mumkin yoki mumkin emasligini bildiradi. To‘g‘ri cache semantikasi takroriy trafik va kechikishni kamaytiradi. Uniform interface resursni identifikatsiya qilish, representation orqali boshqarish, self-descriptive message va hypermedia tamoyillarini birlashtiradi. Layered system clientga yakuniy server bilanmi yoki proxy va gateway orqali gaplashayotganini bilmasdan ishlash imkonini beradi.
Code-on-demand ixtiyoriy cheklov bo‘lib, server clientga bajariladigan kod yuborishini nazarda tutadi. Brauzerga JavaScript yuborilishi bunga misol bo‘la oladi.
HTTP semantikasi
GET safe va idempotent, ya’ni u resurs holatini o‘zgartirish maqsadida ishlatilmaydi va takroriy yuborish bir xil mo‘ljallangan ta’sirga ega. PUT va DELETE idempotent hisoblanadi. POST odatda idempotent emas. API ushbu semantikani saqlasa, client, proxy va retry mexanizmlari so‘rovni to‘g‘ri boshqaradi.
Status code natijani, headerlar esa cache, autentifikatsiya, media type va boshqa metama’lumotni bildiradi. 201 Created yangi resurs yaratilganini, 404 Not Found resurs topilmaganini ko‘rsatadi. Faqat body ichida success: false yozib, barcha javobga 200 berish HTTP vositalarining semantikasini zaiflashtiradi.
API versiyalash
Representation maydonini o‘zgartirish clientlarga ta’sir qilishi mumkin. Versiya URI, header yoki media type orqali ifodalanadi. Orqaga mos o‘zgarishlar, deprecation muddati va hujjatlashtirilgan xato formati client integratsiyasini barqaror saqlaydi. RESTning o‘zi bitta majburiy versiyalash usulini belgilamaydi.
Hypermedia
Hypermedia as the Engine of Application State tamoyiliga ko‘ra, server representation ichida client bajarishi mumkin bo‘lgan keyingi amallarga havolalar beradi. Client URI tuzilishini qo‘lda yasash o‘rniga javobdagi link va relationlardan foydalanadi. Amaliy “REST API”larning ko‘pi resurs, HTTP metod va statelesslikni qo‘llasa ham, hypermedia darajasiga to‘liq amal qilmaydi. Shu sababli RESTga moslikni bitta JSON shakli bilan emas, cheklovlarning qanchasi saqlangani bilan baholash kerak.
Bog‘liq tushunchalar
HTTP, API, resource, URI, representation, idempotentlik, status code