REST کا جائزہ۔ حصہ 1: آرام کیا ہے؟

ہیلو، آج ہم ایک بہت ہی دلچسپ، اور سب سے اہم بات، لیبر مارکیٹ میں طلب کے مطابق موضوع کا مطالعہ کریں گے - REST۔ ہم REST کے جائزہ کو تین حصوں میں تقسیم کریں گے:

1. پہلے حصے میں، ہم REST کی تاریخ کو چھوئیں گے اور ان اصولوں کو بیان کریں گے جن پر REST کی بنیاد ہے۔

2. دوسرے میں، ہم دیکھیں گے کہ HTTP پروٹوکول کے ذریعے کلائنٹ اور سرور کے درمیان مواصلت کیسے ہوتی ہے۔

3. تیسرے میں، ہم ایک چھوٹی سی RESTful ایپلی کیشن لکھیں گے، جسے ہم پوسٹ مین پروگرام کے ذریعے جانچیں گے۔

مضمون کا مقصد مندرجہ ذیل اصطلاحات سے واقف قارئین کے لیے ہے:

• HTTP؛
• URL اور URI؛
• JSON اور کچھ حد تک XML؛
• انحصار انجکشن.

حصہ 1. REST کیا ہے؟

REST، IT کی دنیا میں بہت سی چیزوں کی طرح، Representational State Transfer کا مخفف ہے ۔ یہ کمپیوٹر نیٹ ورک میں تقسیم شدہ نظام کے اجزاء کے درمیان تعامل کا ایک تعمیراتی انداز ہے۔ سادہ لفظوں میں، REST کسی نظام کے مختلف اجزاء کے درمیان تعامل کا ایک انداز (ڈیٹا ایکسچینج) متعین کرتا ہے، جن میں سے ہر ایک جسمانی طور پر مختلف جگہوں پر واقع ہو سکتا ہے۔ یہ آرکیٹیکچرل اسٹائل رکاوٹوں کے ایک مستقل سیٹ کی نمائندگی کرتا ہے جو تقسیم شدہ نظام کو ڈیزائن کرتے وقت غور کیا جاتا ہے۔ ان پابندیوں کو بعض اوقات REST اصول کہا جاتا ہے۔ ان میں سے زیادہ نہیں، صرف 6 ٹکڑے ہیں۔ ہم ان کے بارے میں تھوڑی دیر بعد بات کریں گے۔

REST کی تاریخ

REST کی اصطلاح 2000 میں اپنے ڈاکٹریٹ مقالہ "آرکیٹیکچرل اسٹائلز اینڈ دی ڈیزائن آف نیٹ ورک بیسڈ سافٹ ویئر آرکیٹیکچرز" میں HTTP پروٹوکول کے تخلیق کاروں میں سے ایک، رائے فیلڈنگ نے وضع کی تھی۔ ہم کہہ سکتے ہیں کہ REST کی اصطلاح ابھی بھی جوان ہے، حالانکہ اس کا تصور ورلڈ وائڈ ویب کی بنیاد پر ہے۔ ہم اس اصطلاح کی ابتدا کی تاریخ میں گہرائی میں نہیں جائیں گے۔ اگر آپ اصل ماخذ میں غوطہ لگانا چاہتے ہیں تو فیلڈنگ کے مقالے پر ایک نظر ڈالیں ۔

باقی پابندیاں اور اصول

جیسا کہ اوپر بتایا گیا ہے، REST اس بات کی وضاحت کرتا ہے کہ تقسیم شدہ نظام کے اجزاء کو ایک دوسرے کے ساتھ کیسے تعامل کرنا چاہیے۔ عام طور پر، یہ درخواست کے جواب کے ذریعے ہوتا ہے۔ وہ جزو جو درخواست بھیجتا ہے اسے کلائنٹ کہا جاتا ہے ۔ وہ جزو جو درخواست پر کارروائی کرتا ہے اور کلائنٹ کو جواب بھیجتا ہے اسے سرور کہتے ہیں ۔ درخواستیں اور جوابات اکثر HTTP (ہائپر ٹیکسٹ ٹرانسفر پروٹوکول) کے ذریعے بھیجے جاتے ہیں۔ عام طور پر، سرور کسی قسم کی ویب ایپلیکیشن ہے۔ کلائنٹ صرف کچھ نہیں بلکہ بہت کچھ ہوسکتا ہے۔ مثال کے طور پر، ایک موبائل ایپلیکیشن جو سرور سے ڈیٹا کی درخواست کرتی ہے۔ یا ایسا براؤزر جو ڈیٹا ڈاؤن لوڈ کرنے کے لیے ویب پیج سے سرور کو درخواستیں بھیجتا ہے۔ ایپلیکیشن A ایپلیکیشن B سے ڈیٹا کی درخواست کر سکتی ہے۔ پھر B کے سلسلے میں A ایک کلائنٹ ہے، اور B A کے سلسلے میں سرور ہے۔ ایک ہی وقت میں، A C، D، D، وغیرہ سے درخواستوں پر کارروائی کر سکتا ہے۔ اس صورت میں، ایپلیکیشن A ایک سرور اور کلائنٹ دونوں ہے۔ یہ سب سیاق و سباق پر منحصر ہے۔ ایک چیز واضح ہے: وہ جزو جو درخواست بھیجتا ہے وہ کلائنٹ ہے۔ وہ جزو جو درخواست وصول کرتا ہے، عمل کرتا ہے اور اس کا جواب دیتا ہے وہ سرور ہے۔ تاہم، ہر وہ نظام نہیں جس کے اجزاء درخواست کے جواب کے ذریعے بات چیت کرتے ہیں ایک REST (یا RESTful) نظام نہیں ہے۔ ایک سسٹم کو آرام دہ سمجھے جانے کے لیے، اسے چھ REST پابندیوں کو "فٹ" کرنا چاہیے:

1. فن تعمیر کو کلائنٹ سرور ماڈل میں لانا

اس حد کی بنیاد ضروریات کا فرق ہے۔ کلائنٹ انٹرفیس کی ضروریات کو سرور کی ضروریات سے الگ کرنا ضروری ہے جو ڈیٹا کو ذخیرہ کرتا ہے۔ یہ حد دوسرے پلیٹ فارمز کے لیے کلائنٹ کوڈ کی پورٹیبلٹی کو بڑھاتی ہے، اور سرور کے حصے کو آسان بنانے سے سسٹم کی اسکیل ایبلٹی بہتر ہوتی ہے۔ "کلائنٹ" اور "سرور" کے درمیان بہت فرق انہیں ایک دوسرے سے آزادانہ طور پر ترقی کرنے کی اجازت دیتا ہے۔

2. حالت کی کمی

REST فن تعمیر کے لیے درج ذیل شرط کو پورا کرنے کی ضرورت ہے۔ درخواستوں کے درمیان، سرور کو کلائنٹ کی حالت اور اس کے برعکس معلومات ذخیرہ کرنے کی ضرورت نہیں ہے۔ کلائنٹ کی تمام درخواستوں کا ڈھانچہ ہونا چاہیے تاکہ سرور کو درخواست مکمل کرنے کے لیے تمام ضروری معلومات حاصل ہوں۔ اس طرح، سرور اور کلائنٹ دونوں پچھلے پیغامات پر بھروسہ کیے بغیر موصول ہونے والے کسی بھی پیغام کو "سمجھ" سکتے ہیں۔

3. کیشنگ

کلائنٹ سرور کے جوابات کیش کر سکتے ہیں۔ ان کو، بدلے میں، واضح طور پر یا واضح طور پر کیش ایبل یا غیر کیچ ایبل کے طور پر نامزد کیا جانا چاہیے، تاکہ کلائنٹس کو بعد کی درخواستوں کے جواب میں باسی یا غلط ڈیٹا موصول نہ ہو۔ کیشنگ کا صحیح استعمال کچھ کلائنٹ-سرور کے تعاملات کو ختم کرنے میں مدد کرتا ہے، مکمل یا جزوی طور پر، نظام کی کارکردگی اور توسیع پذیری کو مزید بڑھاتا ہے۔

4. انٹرفیس کی یکسانیت

REST فن تعمیر کی بنیادی ضروریات میں ایک متحد، یکساں انٹرفیس شامل ہے۔ کلائنٹ کو ہمیشہ یہ سمجھنا چاہیے کہ اسے کس فارمیٹ میں اور کن پتوں پر درخواست بھیجنے کی ضرورت ہے، اور سرور کو یہ بھی سمجھنا چاہیے کہ اسے کلائنٹ کی درخواستوں کا جواب کس فارمیٹ میں دینا چاہیے۔ یہ کلائنٹ-سرور کے تعامل کے لیے ایک متحد فارمیٹ ہے، جو یہ بتاتا ہے کہ کیا، کہاں، کس شکل میں اور کیسے بھیجنا ہے اور یہ ایک متحد انٹرفیس ہے۔

5. تہیں

پرتیں نیٹ ورکس کی درجہ بندی کی ساخت کا حوالہ دیتی ہیں۔ کبھی کبھی کلائنٹ سرور کے ساتھ براہ راست بات چیت کرسکتا ہے، اور بعض اوقات یہ صرف ایک انٹرمیڈیٹ نوڈ کے ساتھ بات چیت کرسکتا ہے۔ انٹرمیڈیٹ سرورز کا استعمال لوڈ بیلنسنگ اور ڈسٹری بیوٹڈ کیشنگ کے ذریعے اسکیل ایبلٹی کو بڑھا سکتا ہے۔ آئیے ایک مثال دیتے ہیں۔ آئیے ایک ایسی موبائل ایپلیکیشن کا تصور کرتے ہیں جو پوری دنیا میں مقبول ہے۔ اس کا لازمی حصہ تصاویر لوڈ کرنا ہے۔ چونکہ لاکھوں صارفین ہیں، ایک سرور اتنا بھاری بوجھ برداشت نہیں کر سکتا۔ نظام کو تہوں میں تقسیم کرنے سے یہ مسئلہ حل ہو جائے گا۔ کلائنٹ انٹرمیڈیٹ نوڈ سے تصویر کی درخواست کرے گا، انٹرمیڈیٹ نوڈ سرور سے تصویر کی درخواست کرے گا جو اس وقت کم سے کم لوڈ ہے، اور کلائنٹ کو تصویر واپس کردے گا۔ اگر یہاں درجہ بندی کے ہر سطح پر کیشنگ کو صحیح طریقے سے لاگو کیا جاتا ہے، تو سسٹم کی اچھی اسکیل ایبلٹی حاصل کی جا سکتی ہے۔

6. کوڈ آن ڈیمانڈ (اختیاری پابندی)

اس حد کا مطلب یہ ہے کہ کلائنٹ ایپلٹس یا اسکرپٹ کی شکل میں سرور سے کوڈ ڈاؤن لوڈ کرکے اپنی فعالیت کو بڑھا سکتا ہے۔

آرام کے فوائد

مندرجہ بالا تمام پابندیوں کی تعمیل کرنے والی ایپلیکیشنز کے درج ذیل فوائد ہیں: وشوسنییتا (کلائنٹ کی ریاست کی معلومات کو ذخیرہ کرنے کی ضرورت نہیں، جو ضائع ہو سکتی ہے)؛

• کارکردگی (کیشے کے استعمال کی وجہ سے)؛
• توسیع پذیری
• تعامل کے نظام کی شفافیت؛
• انٹرفیس کی سادگی؛
• اجزاء کی پورٹیبلٹی؛
• تبدیلیاں کرنے میں آسانی؛
• نئی ضروریات کے مطابق ڈھالنے کی صلاحیت۔

حصہ 2: کلائنٹ اور سرور کے درمیان مواصلت حصہ 3: اسپرنگ بوٹ میں ایک آرام دہ سروس بنانا