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

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

• گراهڪ (گراهڪ)
• آرڊر (ڪسٽمر آرڊر)
• شيون (پراڊڪٽس)

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

درخواستون

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

• HTTP جو طريقو
• هيڊر
• URI
• جسم جي درخواست

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

URIs ۽ وسيلن

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

• گراهڪ (گراهڪ)
• آرڊر (ڪسٽمر آرڊر)
• شيون (پراڊڪٽس)

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

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

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

• /customers/4/orders — صارف نمبر 4 پاران ڪيل سڀني آرڊرن جو URI
• /customers/1/orders/12 — آرڊر نمبر 12 جو URI ڪسٽمر نمبر 1 پاران ڪيو ويو.

جيڪڏهن اسان وڌيڪ پراڊڪٽس شامل ڪندي توسيع جاري رکون ٿا، اسان حاصل ڪريون ٿا:

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

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

HTTP جو طريقو

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

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

مٿو

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

• متن - ٽيڪسٽ/سادو، ٽيڪسٽ/سي ايس ايس، ٽيڪسٽ/html
• تصوير — تصوير/png، تصوير/jpeg، تصوير/gif
• آڊيو — آڊيو/wav، آڊيو/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" : "+1 (222) 333-4444"
}

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

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

جواب

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

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

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

HTTP جوابي ڪوڊ

اچو ته وڌيڪ تفصيل سان HTTP جوابي ڪوڊس تي غور ڪريو. هڪ HTTP اسٽيٽس ڪوڊ HTTP پروٽوڪول ذريعي ڪيل درخواستن جي سرور جي جواب جي پهرين لائن جو حصو آهي. اهو هڪ عددي عدد آهي جنهن ۾ ٽن ڏهاڪن جي عددن تي مشتمل آهي. پهريون نمبر اشارو ڪري ٿو ڪلاس جي جوابي اسٽيٽس ڪوڊ. جوابي ڪوڊ عام طور تي انگريزي ۾ هڪ وضاحتي جملي جي پٺيان هوندو آهي، هڪ خلا سان الڳ ٿيل. هي جملو جواب ڏيڻ لاء هڪ انساني پڙهڻ وارو سبب آهي. مثال:

• 201 ٺاهي وئي
• 401 غير مجاز
• 507 ڪافي اسٽوريج

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

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

REST جو جائزو. حصو 3: اسپرنگ بوٽ تي آرام واري خدمت جي تعمير