JavaRush /Java blogi /Random-UZ /REST haqida umumiy fikr. 2-qism: Mijoz va server o'rtasid...

REST haqida umumiy fikr. 2-qism: Mijoz va server o'rtasidagi aloqa

Guruhda nashr etilgan
1-qism: REST nima Bu bo'limda mijoz va server o'rtasida aloqa qanday sodir bo'lishini batafsil ko'rib chiqamiz. Yo'l davomida biz yangi atamalarni ochib beramiz va ularga tushuntirishlar beramiz. REST haqida umumiy fikr.  2-qism: mijoz va server o'rtasidagi aloqa - 1Hamma narsa aniq bo'lishi uchun biz RESTful ilovasi misolida mijoz-server aloqasini tahlil qilamiz. Aytaylik, biz mijozlar va ularning buyurtmalari haqidagi ma'lumotlarni saqlashga qodir bo'lgan veb-ilovani ishlab chiqmoqdamiz. Bular. bizning tizimimiz ba'zi ob'ektlarni boshqarishga qodir: ularni yaratish, tahrirlash, o'chirish va ular haqida ma'lumot berish. Ushbu sub'ektlar quyidagilar bo'ladi:
  • mijozlar - mijozlar;
  • buyurtmalar - mijozlar buyurtmalari;
  • buyumlar - tovarlar.
REST arxitekturasida mijozlar ma'lumotlarni olish yoki o'zgartirish uchun serverga so'rovlar yuboradilar va serverlar mijozlarga ularning so'rovlariga javoblar yuboradilar.

So'rovlar

Mijoz so'rovlari deyarli har doim HTTP orqali amalga oshiriladi. Umuman olganda, HTTP so'rovlari bir nechta komponentlardan iborat:
  • HTTP usuli;
  • sarlavha;
  • URI;
  • so'rov organi.
Quyida biz har bir tarkibiy qismni batafsil ko'rib chiqamiz.

URI va manbalar

Mijozlar so'rovlar orqali oladigan yoki o'zgartiradigan ma'lumotlar resurslar deb ataladi. Mijoz va server o'zaro aloqasining asosi resurslarni manipulyatsiya qilishdir. REST-dagi manbalar nom berilishi mumkin bo'lgan har qanday narsadir. Qaysidir ma'noda, bu Java tilidagi sinflarga o'xshaydi. Java-da biz hamma narsa uchun sinf yaratishimiz mumkin. RESTda ham xuddi shunday - resurs har qanday bo'lishi mumkin: foydalanuvchi, hujjat, hisobot, buyurtma. Bularning barchasi biron bir ob'ektning mavhumligi yoki aniq narsa bo'lishi mumkin, masalan, fayl - rasm, video, animatsiya, PDF fayl. Bizning misolimiz uchun bizda 3 ta manba mavjud:
  • mijozlar - mijozlar;
  • buyurtmalar - mijozlar buyurtmalari;
  • buyumlar - tovarlar.
Mijozlar so'rovlarni so'nggi nuqtalar yoki so'nggi nuqtalarga yuboradilar. Oddiy qilib aytganda, so'nggi nuqta tarmoqdagi manzilga o'xshaydi. Chuqurroq o'tish uchun so'nggi nuqta URI hisoblanadi : mavhum yoki jismoniy manbani aniqlaydigan belgilar ketma-ketligi. Yagona resurs identifikatori - yagona resurs identifikatori. Ba'zan so'nggi nuqta yoki URI yo'l deb ataladi - manbaga yo'l. Ushbu maqolaning maqsadlari uchun biz URI atamasidan foydalanamiz. Har bir maxsus resurs noyob URIga ega bo'lishi kerak. Har bir resurs har doim o'z URI-ga ega bo'lishini ta'minlash uchun javobgarlik server ishlab chiqaruvchisi zimmasiga tushadi. Bizning misolimizda biz ishlab chiquvchilarmiz, shuning uchun biz buni qanday bilsak, shunday qilamiz. Relyatsion ma'lumotlar bazasida asosiy kalitni ma'lum bir raqamli identifikatorga o'rnatish odatiy hol bo'lgani kabi, RESTda har bir resurs o'z identifikatoriga ega. Ko'pincha REST-dagi resurs identifikatori ushbu resurs haqidagi ma'lumotlar saqlanadigan ma'lumotlar bazasidagi yozuvning identifikatoriga mos keladi. REST URI odatda ba'zi manbalarni tavsiflovchi otning ko'plik shaklidan boshlanadi. Masalan, mijozlar so'zidan. Keyinchalik, identifikator slash orqali ko'rsatiladi - ma'lum bir mijozning identifikatori. Misollar:
  • /mijozlar - barcha mavjud mijozlarning URI kodlari;
  • /mijozlar/23 - ma'lum bir mijozning URI, ya'ni ID=23 bo'lgan mijoz;
  • /mijozlar/4 - ma'lum bir mijozning URI, ya'ni ID=4 bo'lgan mijoz.
Lekin bu hammasi emas. Biz URI ni unga buyurtmalar qo'shish orqali kengaytirishimiz mumkin:
  • /mijozlar/4/buyurtmalar — №4 mijozning barcha buyurtmalarining URI;
  • /mijozlar/1/buyurtmalar/12 - 1-sonli mijozning 12-son buyrug'ining URI.
Agar biz ushbu zanjirni davom ettirsak va tovarlarni qo'shsak, biz quyidagilarni olamiz:
  • /mijozlar/1/buyurtmalar/12/moddalar - 1-sonli mijoz tomonidan tuzilgan 12-sonli buyurtma bo'yicha barcha mahsulotlar ro'yxatining URI.
Yuvalash darajalari bilan kalit URI-larni intuitiv qilishdir.

HTTP usuli

HTTP usuli (inglizcha HTTP usuli) - bu resursdagi asosiy operatsiyani ko'rsatadigan boshqaruv va ajratgichlardan tashqari har qanday belgilar ketma-ketligi. Bir nechta umumiy HTTP usullari mavjud. Biz RESTful xizmatlarida eng ko'p ishlatiladiganlarni sanab o'tamiz:
  • GET - ma'lum bir resurs (ID orqali) yoki resurslar to'plami haqida ma'lumot olish uchun ishlatiladi;
  • POST - yangi resurs yaratish uchun ishlatiladi;
  • PUT - resursni o'zgartirish uchun ishlatiladi (ID orqali);
  • DELETE - resursni o'chirish uchun ishlatiladi (ID orqali).

Sarlavhalar

So'rovlar va javoblar HTTP sarlavhalarini o'z ichiga oladi. Ular so'rov (yoki javob) haqida qo'shimcha ma'lumot yuboradilar. Sarlavhalar kalit-qiymat juftligidir. Vikipediya sahifasida eng keng tarqalgan sarlavhalar ro'yxatini o'qishingiz mumkin . REST yordamida mijozlar ko'pincha serverga o'z so'rovlarida Accept sarlavhasini yuborishlari mumkin. Mijoz undan javob olishni kutayotgan formatda serverga xabar berish kerak. MIME tipi deb ataladigan ro'yxatda turli format variantlari mavjud. MIME (Ko'p maqsadli Internet pochta kengaytmalari) - bu ma'lumotlarni kodlash va xabarlarni Internet orqali yuborish uchun formatlash uchun spetsifikatsiya. Har bir MIME turi ikki qismdan iborat bo'lib, ular chiziq bilan ajratilgan: tur va pastki tur. Har xil turdagi fayllar uchun MIME turlariga misollar:
  • matn - matn/plain, text/css, text/html;
  • tasvir - rasm/png, tasvir/jpeg, tasvir/gif;
  • audio - audio/wav, audio/mpeg;
  • video - video/mp4, video/ogg;
  • ilova - ilova/json, dastur/pdf, dastur/xml, ilova/oktet-stream.
Umuman olganda, so'rov quyidagi sarlavhaga ega bo'lishi mumkin:
Accept:application/json
Ushbu sarlavha serverga mijoz JSON formatida javob olishni kutayotganini bildiradi.

So'rov organi

Mijoz tomonidan serverga yuborilgan xabar. So'rovning tanasi bor yoki yo'qligi HTTP so'rovi turiga bog'liq. Misol uchun, GET va DELETE so'rovlari odatda so'rovlar tanasini o'z ichiga olmaydi. Ammo PUT va POST quyidagilarni o'z ichiga olishi mumkin: bu so'rov turining funktsional maqsadi haqida. Axir, ma'lumotlarni qabul qilish va uni id (URL-da uzatiladigan) bo'yicha o'chirish uchun siz serverga qo'shimcha ma'lumotlarni yuborishingiz shart emas. Lekin yangi resurs (POST so'rovi) yaratish uchun siz ushbu resursni o'tkazishingiz kerak. Xuddi shu narsa mavjud manbani o'zgartirish uchun ham amal qiladi. RESTda XML yoki JSON formatlari ko'pincha so'rovning asosiy qismini uzatish uchun ishlatiladi. Eng keng tarqalgan format JSON. Aytaylik, biz serverga so'rov yubormoqchimiz va unda yangi resurs yaratamiz. Esingizda bo'lsa, misol sifatida biz mijozlar buyurtmalarini boshqaradigan dasturni ko'rib chiqdik. Aytaylik, biz yangi mijoz yaratmoqchimiz. Bizning holatlarimizda biz mijozlar haqida quyidagi ma'lumotlarni saqlaymiz: Ism Email Telefon raqami Keyin bunday so'rovning asosiy qismi quyidagi JSON bo'lishi mumkin:
{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+7 (191) 746-43-23"
}

So'rovlarni birlashtirish

Shunday qilib, biz mijozning so'rovi nimadan iborat bo'lishi mumkinligini ko'rib chiqdik. Keling, so'rovlarning tavsifi bilan bir nechta misollarini keltiramiz
So'rov Tavsif

GET /clients/23
Accept : application/json, application/xml
Json yoki xml formatida 23-sonli mijoz haqida ma'lumot oling

POST /clients
{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+7 (191) 746-43-23"
}
Quyidagi maydonlar bilan yangi mijoz yarating:
Ism - Amigo
Email - amigo@jr.com
Tel. — +7 (191) 746-43-23

PUT /clients/1
{
  "name" : "Ben",
  "email" : "bigben@jr.com",
  "phone" : "+380 (190) 346-42-13"
}
№1 mijozni quyidagicha tahrirlang:
Ism - Ben
Email - bigben@jr.com
Tel. — +380 (190) 346-42-13

DELETE /clients/12/orders/6
12-sonli mijozdan 6-sonli buyurtmani tizimdan o'chirish

Javoblar

Serverning javoblari haqida bir necha so'z aytaylik. Javob odatda quyidagi qismlardan iborat:
  • javob kodi;
  • sarlavhalar;
  • javob organi.
Umuman olganda, javob sarlavhalari so'rov sarlavhalaridan unchalik farq qilmaydi. Bundan tashqari, ba'zi sarlavhalar ham javoblarda, ham so'rovlarda ishlatiladi. Menimcha, javobning tanasi bilan hamma narsa aniq. Tana ko'pincha mijoz so'ragan ma'lumotlarni qaytaradi. GET so'rovlari uchun ma'lumotni bir xil JSON formatida qaytarish mumkin. Ammo oxirgi qism biroz qiziqarliroq.

HTTP javob kodlari

Keling, HTTP javob kodlarini batafsil ko'rib chiqaylik. Vikipediyadan iqtibos: HTTP holat kodi HTTP protokoli orqali soʻrovlar uchun server javobining birinchi qatorining bir qismidir. Bu uchta o'nlik raqamdan iborat butun son. Birinchi raqam shartning sinfini ko'rsatadi. Javob kodidan keyin odatda bo'sh joy bilan ajratilgan ingliz tilidagi tushuntirish iborasi keladi, bu esa odamga ushbu aniq javobning sababini tushuntiradi. Misollar:
  • 201 yaratilgan;
  • 401 Ruxsatsiz;
  • 507 Xotira yetarli emas.
Mijoz javob kodidan o'z so'rovi natijalarini bilib oladi va keyingi harakatlarni belgilaydi. Javob kodlari bir necha guruhlarga bo'linadi:
  • 1XX - axborot;
  • 2XX - mijozning so'rovini muvaffaqiyatli qabul qilish va ko'rib chiqish hollari to'g'risida xabar berish;
  • 3XX - mijozga operatsiyani muvaffaqiyatli yakunlash uchun odatda boshqa URI-dan foydalangan holda boshqa so'rov yuborish zarurligi haqida xabar bering;
  • 4XX - mijoz xatosi. Masalan, noto'g'ri tuzilgan so'rov yoki mijoz mavjud bo'lmagan resurs so'raganda yuzaga kelishi mumkin bo'lgan taniqli 404 Not Found kodi;
  • 5XX - server xatosi. Agar server xatosi tufayli operatsiya bajarilmasa, mijozga qaytariladi.
Bu yerda barcha kodlar haqida ko'proq o'qishingiz mumkin . 1-qism: REST nima 3-qism: Spring Boot-da RESTful xizmatini yaratish
Izohlar
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION