REST کا جائزہ۔ حصہ 2: کلائنٹ اور سرور کے درمیان مواصلت

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

• گاہک (گاہک)
• آرڈرز (کسٹمر آرڈرز)
• اشیاء (مصنوعات)

ایک آرام دہ فن تعمیر میں، کلائنٹ ڈیٹا کو بازیافت کرنے یا اس میں ترمیم کرنے کے لیے سرور کو درخواستیں بھیجتے ہیں، اور پھر سرور کلائنٹ کو ان کی درخواستوں کے جوابات بھیجتے ہیں۔

درخواستیں

کلائنٹ کی درخواستیں تقریبا ہمیشہ HTTP پروٹوکول کا استعمال کرتے ہوئے کی جاتی ہیں۔ عام طور پر، HTTP درخواستیں کئی اجزاء پر مشتمل ہوتی ہیں:

• HTTP طریقہ
• ہیڈر
• URI
• جسم کی درخواست کریں

ذیل میں ہم ہر ایک جز پر مزید تفصیل سے غور کریں گے۔

URIs اور وسائل

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

• گاہک (گاہک)
• آرڈرز (کسٹمر آرڈرز)
• اشیاء (مصنوعات)

کلائنٹس وسائل کے مقامات پر درخواستیں بھیجتے ہیں جنہیں اینڈ پوائنٹس کہا جاتا ہے۔ سیدھے الفاظ میں، ایک اختتامی نقطہ نیٹ ورک پر ایک ایڈریس کی طرح ہے۔ گہرائی میں غوطہ خوری کرتے ہوئے، ہم کہہ سکتے ہیں کہ ایک اختتامی نقطہ URI ہے ، یعنی حروف کا ایک سلسلہ جو کسی تجریدی یا جسمانی وسائل کی شناخت کرتا ہے۔ یونیفارم ریسورس آئیڈینٹیفائر (URI) بعض اوقات ایک اینڈ پوائنٹ، یا URI، کو پاتھ کہا جاتا ہے، یعنی وسائل کا راستہ۔ اس مضمون کے مقاصد کے لیے، ہم URI کی اصطلاح استعمال کریں گے۔ ہر مخصوص وسائل کا ایک منفرد URI ہونا ضروری ہے۔ سرور ڈیولپر اس بات کو یقینی بنانے کے لیے ذمہ دار ہے کہ ہر وسیلہ کا ہمیشہ اپنا URI ہو۔ ہماری مثال میں، ہم ڈویلپر ہیں، لہذا ہم اسے اس طرح کریں گے جس طرح سے ہم جانتے ہیں۔ جس طرح اکثر عددی شناخت کنندگان کو متعلقہ ڈیٹا بیس میں بنیادی کلیدوں کے طور پر تفویض کرنے کا رواج ہوتا ہے، اسی طرح REST میں ہر وسائل کی اپنی شناخت بھی ہوتی ہے۔ REST میں وسائل کی ID اکثر ڈیٹا بیس میں موجود ریکارڈ کی ID سے مماثل ہوتی ہے جو وسائل کے بارے میں معلومات کو ذخیرہ کرتا ہے۔ REST URIs روایتی طور پر کسی اسم کی جمع شکل سے شروع ہوتے ہیں جو کچھ وسائل کو بیان کرتے ہیں۔ مثال کے طور پر، "گاہک"۔ اس کے بعد ایک سلیش، اور پھر کسی خاص صارف کا شناخت کنندہ (ID) آتا ہے۔ مثالیں:

• /گاہک - تمام دستیاب صارفین کا 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 — گاہک نمبر 1 کے ذریعہ ترتیب نمبر 12 میں تمام مصنوعات کی فہرست کا URI۔

جیسا کہ ہم گھوںسلا کی سطحوں کو شامل کرتے ہیں، اہم چیز URIs کو بدیہی بنانا ہے۔

HTTP طریقہ

HTTP طریقہ کسی بھی حروف کی ترتیب ہے (سوائے کنٹرول حروف اور حد بندیوں کے)، جو وسائل پر کیے جانے والے مرکزی آپریشن کی نشاندہی کرتا ہے۔ HTTP کے کئی عام طریقے ہیں۔ ہم ان کی فہرست بنائیں گے جو RESTful خدمات میں اکثر استعمال ہوتے ہیں:

• GET — کسی خاص وسائل کے بارے میں (اس کی ID کے ذریعے) یا وسائل کے مجموعے کے بارے میں معلومات حاصل کریں۔
• پوسٹ کریں - ایک نیا وسیلہ بنائیں
• PUT - ایک وسیلہ تبدیل کریں (اس کی ID کے ذریعے)
• DELETE — ایک وسیلہ حذف کریں (اس کی ID کے ذریعے)

ہیڈرز

درخواستوں کے ساتھ ساتھ جوابات میں HTTP ہیڈر ہوتے ہیں۔ وہ درخواست (یا جواب) کے بارے میں اضافی معلومات فراہم کرتے ہیں۔ ہیڈرز کلیدی قدر کے جوڑے ہیں۔ آپ ویکیپیڈیا پر سب سے عام ہیڈروں کی فہرست دیکھ سکتے ہیں ۔ جہاں تک REST کا تعلق ہے، کلائنٹ اکثر سرور کو درخواستوں میں "قبول کریں" ہیڈر بھیجتے ہیں۔ یہ ہیڈر سرور کو یہ بتانے کے لیے درکار ہے کہ کلائنٹ کو کس فارمیٹ میں جواب موصول ہونے کی توقع ہے۔ MIME اقسام کی فہرست میں مختلف فارمیٹس دیے گئے ہیں۔ MIME (ملٹی پرپز انٹرنیٹ میل ایکسٹینشنز) معلومات کو انکوڈنگ کرنے اور پیغامات کی فارمیٹنگ کے لیے ایک تصریح ہے تاکہ انہیں انٹرنیٹ پر بھیجا جا سکے۔ ہر MIME قسم دو حصوں پر مشتمل ہوتی ہے جو سلیش سے الگ ہوتے ہیں — ایک قسم اور ذیلی قسم۔ مختلف قسم کی فائلوں کے لیے MIME اقسام کی مثالیں:

• متن - متن/سادہ، متن/سی ایس ایس، متن/HTML
• تصویر — image/png، image/jpeg، image/gif
• آڈیو - آڈیو/ویو، آڈیو/ ایم پی ای جی
• ویڈیو — video/mp4، video/ogg
• ایپلیکیشن — ایپلیکیشن/json، ایپلیکیشن/پی ڈی ایف، ایپلیکیشن/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: اسپرنگ بوٹ پر ایک آرام دہ سروس کی تعمیر