REST جو جائزو. حصو 2: ڪلائنٽ ۽ سرور جي وچ ۾ رابطي

حصو 1: REST ڇا آهي هن حصي ۾ اسان هڪ ويجھو نظر وجهنداسين ته ڪئين ڪميونيڪيشن ڪلائنٽ ۽ سرور جي وچ ۾ ٿئي ٿي. رستي ۾، اسان نئين شرطن کي ظاهر ڪنداسين ۽ انهن جي وضاحت ڪنداسين. هر شي کي صاف ڪرڻ لاءِ (ٿيڻ) واضح ڪرڻ لاءِ، اسان تجزيو ڪنداسين ڪلائنٽ-سرور ڪميونيڪيشن جو مثال استعمال ڪندي ڪجهه RESTful ايپليڪيشن. اچو ته چئو ته اسان هڪ ويب ايپليڪيشن ٺاهي رهيا آهيون جيڪا گراهڪن ۽ انهن جي آرڊر بابت معلومات محفوظ ڪرڻ جي قابل آهي. اهي. اسان جو سسٽم ڪجهه ادارن کي هٿي ڏيڻ جي قابل آهي: انهن کي ٺاهڻ، انهن کي تبديل ڪرڻ، انهن کي حذف ڪرڻ، ۽ انهن بابت معلومات مهيا ڪرڻ. اهي ادارا هوندا:

• کلائنٽ - گراهڪ؛
• آرڊر - ڪسٽمر آرڊر؛
• شيون- سامان.

REST فن تعمير ۾، گراهڪ سرور ڏانهن ڊيٽا حاصل ڪرڻ يا تبديل ڪرڻ لاءِ درخواستون موڪليندا آهن، ۽ سرور موڪليندا آهن جوابن جي ڪلائنٽ کي انهن جي درخواستن تي.

درخواستون

ڪلائنٽ جون درخواستون تقريبن هميشه HTTP تي ڪيون وينديون آهن. عام طور تي، HTTP درخواستون ڪيترن ئي حصن تي مشتمل آهن:

• HTTP جو طريقو؛
• عنوان؛
• URI؛
• جسم جي درخواست.

هيٺ اسين وڌيڪ تفصيل سان هر جزو جي حصي کي ڏسندا.

URI ۽ وسيلا

ڊيٽا جيڪا ڪلائنٽ حاصل ڪري ٿي يا درخواستن ذريعي تبديل ڪري ٿي وسيلن کي سڏيو ويندو آهي. ڪلائنٽ-سرور رابطي جو بنياد وسيلن جي ورڇ آهي. REST ۾ وسيلا ڪجھ به آھن جن کي نالو ڏئي سگھجي ٿو. هڪ لحاظ کان، اهي جاوا ۾ طبقن وانگر آهن. جاوا ۾ اسان ڪنهن به شيءِ لاءِ ڪلاس ٺاهي سگهون ٿا. اهو REST ۾ ساڳيو آهي - هڪ وسيلو ڪجهه به ٿي سگهي ٿو: هڪ صارف، هڪ دستاويز، هڪ رپورٽ، هڪ آرڊر. اهو سڀ ڪجهه ٿي سگهي ٿو يا ته ڪنهن اداري جو خلاصو يا ڪجهه ڪنڪريٽ، مثال طور، هڪ فائل - هڪ تصوير، وڊيو، اينيميشن، PDF فائل. اسان جي مثال لاء، اسان وٽ 3 وسيلا آهن:

• کلائنٽ - گراهڪ؛
• آرڊر - ڪسٽمر آرڊر؛
• شيون- سامان.

ڪلائنٽ درخواستن کي نام نهاد آخري پوائنٽن، يا آخري پوائنٽن ڏانهن موڪليندا آهن. ان کي بلڪل سادو رکڻ لاء، هڪ آخري پوائنٽ ڪجهه آهي جهڙوڪ نيٽ ورڪ تي ايڊريس. اونهي وڃڻ لاءِ، هڪ آخري نقطو هڪ URI آهي : اکرن جو هڪ سلسلو جيڪو هڪ خلاصو يا جسماني وسيلن جي سڃاڻپ ڪري ٿو. Uniform Resource Identifier - هڪ گڏيل وسيلن جي سڃاڻپ ڪندڙ. ڪڏهن ڪڏهن آخري نقطي، يا URI، سڏيو ويندو آهي رستو - هڪ وسيلن ڏانهن رستو. هن آرٽيڪل جي مقصدن لاءِ، اسان استعمال ڪنداسين اصطلاح URI. هر مخصوص وسيلن کي هڪ منفرد URI هجڻ گهرجي. انهي ڳالهه کي يقيني بڻائڻ جي ذميواري آهي ته هر وسيلن کي هميشه پنهنجي پنهنجي يو آر آئي آهي سرور ڊولپر جي ڪلهن تي. اسان جي مثال ۾، اسان ڊولپر آهيون، تنهنڪري اسان اهو ڪنداسين ته اسان اهو ڪيئن ڄاڻون ٿا. جيئن ته هڪ تعلقي ڊيٽابيس ۾ اهو عام طور تي هڪ خاص عددي ID تي پرائمري ڪيچ مقرر ڪرڻ لاءِ رواج آهي، REST ۾ هر وسيلن جي پنهنجي سڃاڻپ آهي. اهو اڪثر ٿئي ٿو ته REST ۾ وسيلن جي ID ڊيٽابيس ۾ رڪارڊ جي ID سان ملي ٿي جنهن ۾ هن وسيلن بابت معلومات محفوظ ڪئي وئي آهي. REST URIs عام طور تي هڪ اسم جي جمع فارم سان شروع ٿئي ٿو جيڪو ڪجهه وسيلن کي بيان ڪري ٿو. مثال طور، لفظ ڪلائنٽ مان. اڳيون، هڪ ID هڪ سليش ذريعي ظاهر ڪيو ويو آهي - هڪ مخصوص ڪلائنٽ جي سڃاڻپ ڪندڙ. مثال:

• /ڪلائنٽس - سڀني موجوده گراهڪن جي URI؛
• /ڪلائنٽس/23 - هڪ مخصوص ڪلائنٽ جو URI، يعني ڪلائنٽ ID = 23 سان؛
• /ڪلائنٽس/4 - هڪ مخصوص ڪلائنٽ جو URI، يعني ڪلائنٽ ID = 4 سان.

پر اهو سڀ ڪجهه ناهي. اسان ان ۾ آرڊر شامل ڪندي URI کي وڌائي سگھون ٿا:

• /ڪلائنٽ/4/آرڊرز - ڪلائنٽ نمبر 4 جي سڀني آرڊرن جو URI؛
• /clients/1/orders/12 - ڪلائنٽ نمبر 1 جو آرڊر نمبر 12 جو URI.

جيڪڏهن اسان هي سلسلو جاري رکون ٿا ۽ سامان شامل ڪريون ٿا، اسان حاصل ڪريون ٿا:

• /clients/1/orders/12/items — آرڊر نمبر 12 ۾ سڀني پراڊڪٽس جي لسٽ جو يو آر آءِ ڪلائنٽ نمبر 1 پاران ٺاهيو ويو آهي.

nesting سطحن سان، اهم آهي URIs کي وجداني بڻائڻ.

HTTP جو طريقو

HTTP طريقو (انگريزي HTTP طريقو) ڪنهن به اکرن جو هڪ سلسلو آهي، سواء ڪنٽرول ۽ جدا ڪندڙ، جيڪو هڪ وسيلن تي مکيه آپريشن کي ظاهر ڪري ٿو. اتي ڪيترائي عام HTTP طريقا آھن. اسان انهن کي لسٽ ڪريون ٿا جيڪي اڪثر استعمال ڪيا ويندا آهن RESTful خدمتن ۾:

• GET - هڪ مخصوص وسيلن جي باري ۾ معلومات حاصل ڪرڻ لاء استعمال ڪيو ويو (ID ذريعي) يا وسيلن جي هڪ مجموعو؛
• پوسٽ - هڪ نئون وسيلو ٺاهڻ لاء استعمال ڪيو؛
• PUT - وسيلن کي تبديل ڪرڻ لاء استعمال ڪيو ويو (ID ذريعي)؛
• DELETE - هڪ وسيلو کي ختم ڪرڻ لاء استعمال ڪيو ويو (ID ذريعي).

مٿو

درخواستون، گڏوگڏ جواب، HTTP هيڊر تي مشتمل آهن. اهي درخواست (يا جواب) بابت اضافي معلومات موڪليندا آهن. هيڊر اهم-قدر جوڙو آهن. توھان وڪيپيڊيا صفحي تي سڀ کان عام عنوانن جي لسٽ پڙھي سگھو ٿا . REST سان، گراهڪ اڪثر ڪري موڪلي سگھن ٿا هڪ قبول هيڊر انهن جي درخواست ۾ سرور ڏانهن. اهو ضروري آهي ته سرور کي خبر ڏيو ته ڪهڙي شڪل ۾ ڪلائنٽ ان کان جواب حاصل ڪرڻ جي اميد رکي ٿو. مختلف فارميٽ جا اختيار پيش ڪيا ويا آھن نام نهاد MIME قسم جي فهرست ۾. MIME (Multipurpose Internet Mail Extensions) معلومات کي انڪوڊنگ ڪرڻ ۽ پيغامن کي فارميٽ ڪرڻ لاءِ هڪ وضاحت آهي ته جيئن اهي انٽرنيٽ تي موڪلي سگهجن. هر MIME قسم ٻن حصن تي مشتمل آهي، هڪ سليش سان الڳ ٿيل: هڪ قسم ۽ هڪ ذيلي قسم. فائلن جي مختلف قسمن لاءِ MIME قسمن جا مثال:

• متن - متن/سادو، ٽيڪسٽ/سي ايس ايس، ٽيڪسٽ/html؛
• تصوير - تصوير/png، تصوير/jpeg، تصوير/gif؛
• آڊيو - آڊيو/واو، آڊيو/mpeg؛
• وڊيو - وڊيو/mp4، وڊيو/ogg؛
• ايپليڪيشن - ايپليڪيشن/جيسن، ايپليڪيشن/پي ڊي ايف، ايپليڪيشن/xml، ايپليڪيشن/آڪٽٽ-اسٽريم.

مجموعي طور تي، درخواست ھيٺ ڏنل سر ٿي سگھي ٿي:

Accept:application/json

هي هيڊر سرور کي ٻڌائي ٿو ته ڪلائنٽ JSON فارميٽ ۾ جواب حاصل ڪرڻ جي اميد رکي ٿو.

جسم جي درخواست

هڪ پيغام جيڪو ڪلائنٽ طرفان سرور ڏانهن موڪليو ويو آهي. ڇا هڪ درخواست جو جسم آهي يا نه ان تي منحصر آهي HTTP درخواست جي قسم تي. مثال طور، GET ۽ DELETE درخواستن ۾ عام طور تي ڪا به درخواست جسم شامل ناهي. پر PUT ۽ POST تي مشتمل ٿي سگھي ٿو: اهو سڀ ڪجهه درخواست جي قسم جي فنڪشنل مقصد بابت آهي. آخرڪار، ڊيٽا حاصل ڪرڻ ۽ ان کي id ذريعي حذف ڪرڻ (جيڪو URL ۾ منتقل ٿيل آهي)، توهان کي سرور ڏانهن اضافي ڊيٽا موڪلڻ جي ضرورت ناهي. پر ھڪڙو نئون وسيلو ٺاھڻ لاءِ (پوسٽ جي درخواست)، توھان کي ھي وسيلو منتقل ڪرڻ جي ضرورت آھي. ساڳيو ئي هڪ موجوده وسيلن کي تبديل ڪرڻ لاء آهي. REST ۾، XML يا JSON فارميٽ اڪثر ڪري استعمال ٿيل آهن درخواست جي جسم کي منتقل ڪرڻ لاء. سڀ کان وڌيڪ عام فارميٽ JSON آهي. فرض ڪريو اسان سرور ڏانهن هڪ درخواست موڪلڻ چاهيون ٿا، ۽ ان ۾ هڪ نئون وسيلو ٺاهيو. جيڪڏهن توهان کي ياد آهي، مثال طور اسان هڪ ايپليڪيشن کي ڏٺو جيڪو ڪسٽمر آرڊر کي منظم ڪري ٿو. اچو ته چئو ته اسان هڪ نئون ڪلائنٽ ٺاهڻ چاهيون ٿا. اسان جي صورت ۾، اسان ڪلائنٽ جي باري ۾ هيٺين معلومات کي ذخيرو ڪندا آهيون: نالو اي ميل فون نمبر پوء اهڙي درخواست جو جسم هيٺ ڏنل JSON ٿي سگهي ٿو:

{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+7 (191) 746-43-23"
}

درخواستون گڏ ڪرڻ

تنهن ڪري، اسان ڏٺو آهي ته ڪلائنٽ جي درخواست ڪهڙي ٿي سگهي ٿي. اچو ته هاڻي وضاحت سان سوالن جا ڪجهه مثال ڏيون

جواب

اچو ته سرور جي جوابن بابت ڪجهه لفظ چئون. جواب عام طور تي هيٺين حصن تي مشتمل آهي:

• جوابي ڪوڊ؛
• هيڊر؛
• جوابي جسم.

عام طور تي، جوابي هيڊرز درخواست جي هيڊرن کان گهڻو مختلف نه آهن. ان کان سواء، ڪجهه هيڊر ٻنهي جوابن ۽ درخواستن ۾ استعمال ڪيا ويا آهن. منهنجو خيال آهي ته جواب جي جسم سان هر شيء واضح آهي. جسم اڪثر ڪري معلومات واپس ڪري ٿو جيڪا ڪلائنٽ درخواست ڪئي. GET درخواستن لاءِ ساڳي JSON فارميٽ ۾ معلومات واپس ڪري سگھجي ٿي. پر آخري حصو ٿورو وڌيڪ دلچسپ آهي.

HTTP جوابي ڪوڊ

اچو ته HTTP جوابي ڪوڊس تي وڌيڪ نظر رکون. هتي وڪيپيڊيا مان هڪ اقتباس آهي: HTTP اسٽيٽس ڪوڊ HTTP پروٽوڪول ذريعي درخواستن لاءِ سرور جي جواب جي پهرين لائن جو حصو آهي. اهو ٽي ڊيسيمل انگن سان هڪ عددي عدد آهي. پهريون انگ اشارو ڪري ٿو درجي جي حالت. جوابي ڪوڊ عام طور تي انگريزيءَ ۾ هڪ وضاحتي جملي جي پٺيان هوندو آهي جيڪو هڪ جاءِ سان جدا ڪيو ويندو آهي، جيڪو شخص کي هن خاص جواب جو سبب ٻڌائيندو آهي. مثال:

• 201 ٺھيل؛
• 401 غير مجاز؛
• 507 ڪافي اسٽوريج.

ڪلائنٽ ان جي درخواست جي نتيجن جي باري ۾ جوابي ڪوڊ مان سکي ٿو ۽ اهو طئي ڪري ٿو ته اڳتي وڌڻ وارا ڪهڙا عمل. جوابي ڪوڊ ڪيترن ئي گروپن ۾ ورهايل آهن:

• 1ХХ - معلوماتي؛
• 2ХХ - ڪلائنٽ جي درخواست جي ڪامياب قبوليت ۽ پروسيسنگ جي ڪيسن بابت ڄاڻ؛
• 3XX - ڪلائنٽ کي ٻڌايو ته آپريشن کي ڪاميابي سان مڪمل ڪرڻ لاء، اهو ضروري آهي ته هڪ ٻي درخواست ڪرڻ، عام طور تي مختلف URI استعمال ڪندي؛
• 4ХХ - ڪلائنٽ جي غلطي. مثال طور، هڪ غلط تعمير ٿيل درخواست يا مشهور 404 نه مليو ڪوڊ، جيڪو ٿي سگهي ٿو جڏهن ڪو ڪلائنٽ غير موجود وسيلن جي درخواست ڪري ٿو؛
• 5ХХ - سرور جي غلطي. ڪلائنٽ ڏانهن واپس آيو جيڪڏهن آپريشن ناڪام ٿي سرور جي غلطي جي ڪري.

توھان وڌيڪ پڙھي سگھوٿا سڀ ڪوڊ بابت هتي . حصو 1: REST ڇا آهي حصو 3: اسپرنگ بوٽ ۾ آرام واري خدمت ٺاهڻ