کلائنٹس اور سرورز کیسے بات چیت کرتے ہیں: HTTP/1.1، HTTP/2، REST، WebSocket، GraphQL، gRPC، اور پروٹوکول بفرز پر ایک مکمل ہینڈ بک۔

میں نے ایک API بنایا اور استعمال کیا۔ میں جانتا ہوں کہ GET کی درخواست کیا ہے، JSON جواب کیسا لگتا ہے، اور اجازت نامے کا ہیڈر کیسے شامل کیا جائے۔ آپ نے REST استعمال کیا ہے، آپ نے GraphQL آزمایا ہے، اور آپ نے شاید gRPC کے بارے میں سنا ہوگا۔

لیکن کیا آپ جانتے ہیں کہ جب آپ کی درخواست ایک درخواست بھیجتی ہے تو اصل میں کیا ہوتا ہے؟ تاروں کے ذریعے کیا حرکت کرتا ہے؟ HTTP/2 چیزوں کو تیز کیوں کرتا ہے؟ جب HTTP پہلے سے کام کرتا ہے تو WebSockets کیوں موجود ہیں؟ بنیادی سطح پر، کیا پروٹوکول بفرز کو JSON سے مختلف بناتا ہے؟

اور آپ کس طرح فیصلہ کرتے ہیں کہ نظام کو ڈیزائن کرتے وقت کون سا مواصلاتی طریقہ استعمال کرنا ہے؟

اس ہینڈ بک کے جوابات یہ ہیں:

یہ APIs کے لیے ابتدائی رہنما نہیں ہے۔ یہ اس بات کا گہرا غوطہ ہے کہ کلائنٹس اور سرورز کس طرح بات چیت کرتے ہیں – پروٹوکولز، ان کے فوائد اور نقصانات، ہر ایک نقطہ نظر کو کیوں بنایا گیا تھا، اور ایک دوسرے کو منتخب کرنے کے پیچھے انجینئرنگ کی ذہنیت۔

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

انڈیکس

بنیادی باتیں: دو مشینیں ایک دوسرے سے کیسے بات کرتی ہیں۔

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

آئی پی ایڈریس اور پورٹ

نیٹ ورک پر موجود ہر ڈیوائس کا ایک IP پتہ ہوتا ہے، ایک منفرد شناخت کنندہ جو پوسٹل ایڈریس کی طرح کام کرتا ہے۔ جب درخواست بھیجتی ہے۔ api.example.comپہلی چیز جو ہوتی ہے وہ ایک DNS تلاش ہے جو انسانی پڑھنے کے قابل نام کو اس طرح کے IP پتے میں ترجمہ کرتا ہے: 93.184.216.34. وہ IP پتہ وہیں ہے جہاں پیکٹ جاتا ہے۔

تاہم، صرف ایک IP ایڈریس کافی نہیں ہے۔ ایک سرور ایک ساتھ درجنوں مختلف خدمات چلا سکتا ہے، بشمول ویب سرور، ڈیٹا بیس، ای میل سرورز، اور SSH ڈیمن۔

بندرگاہیں آپریٹنگ سسٹم کو بتاتی ہیں کہ کون سی سروس کو آنے والے کنکشن کو سنبھالنا چاہیے۔ پورٹ 80 HTTP کے لیے ایک عام بندرگاہ ہے۔ پورٹ 443 HTTPS کے لیے ہے۔ پورٹ 5432 PostgreSQL کے لیے ہے۔ پورٹ 22 SSH کے لیے ہے۔ جب آپ کال کرتے ہیں۔ api.example.com/usersکیا آپ واقعی فون پر ہیں؟ api.example.com:443/users. آپ کا براؤزر خود بخود پورٹ کو آباد کر دے گا۔

TCP: ایک قابل اعتماد فاؤنڈیشن

زیادہ تر ویب مواصلات ٹرانسمیشن کنٹرول پروٹوکول (TCP) پر چلتی ہیں۔ TCP ایک کنکشن پر مبنی پروٹوکول ہے۔ اس کا مطلب یہ ہے کہ کسی بھی ڈیٹا کے تبادلے سے پہلے، دونوں فریق ایک کنکشن قائم کرنے کے لیے مصافحہ کرتے ہیں۔

TCP ہینڈ شیک تین مراحل میں کام کرتا ہے، اس لیے اسے تین طرفہ مصافحہ کہا جاتا ہے۔

Client                    Server
  |                          |
  |-------- SYN ----------->|   "I want to connect"
  |                          |
  |<------- SYN-ACK --------|   "Okay, I acknowledge. Ready?"
  |                          |
  |-------- ACK ----------->|   "Great, let's go"
  |                          |
  [Connection established]

SYN کا مطلب مطابقت پذیری ہے۔ ACK کا مطلب ہے تسلیم۔ ان تین پیکٹوں کے بعد، کنکشن موجود ہے اور ڈیٹا بہہ سکتا ہے۔

TCP تین چیزوں کی ضمانت دیتا ہے جو قابل اعتماد مواصلات کی بنیاد ہیں:

1. ترسیل: اگر ٹرانسمیشن کے دوران پیکٹ گم ہو جاتا ہے، تو TCP اس کا پتہ لگاتا ہے اور خود بخود اسے دوبارہ منتقل کر دیتا ہے۔ درخواست کی پرت کو پیکٹ کے نقصان کے بارے میں فکر کرنے کی ضرورت نہیں ہے۔

2. حکم: پیکٹ اسی ترتیب سے آتے ہیں جس ترتیب سے وہ بھیجے گئے تھے۔ جب پیکٹ آرڈر سے باہر ہو جاتے ہیں (جو اکثر حقیقی نیٹ ورکس میں ہوتا ہے)، TCP پیکٹوں کو ایپلی کیشن تک پہنچانے سے پہلے دوبارہ ترتیب دیتا ہے۔

3. غلطی کا پتہ لگانا: ہر TCP پیکٹ میں ایک چیکسم ہوتا ہے۔ اگر ٹرانسمیشن کے دوران ڈیٹا کرپٹ ہو جاتا ہے، تو TCP خراب شدہ پیکٹ کا پتہ لگاتا ہے، اسے گرا دیتا ہے، اور دوبارہ ٹرانسمیشن کی درخواست کرتا ہے۔

یہ وشوسنییتا ایک قیمت پر آتی ہے، بشمول ہینڈ شیک اوور ہیڈ، ایکنولجمنٹ پیکٹ، اور ری ٹرانسمیشن منطق۔

بہت سے استعمال کے معاملات میں، یہ قیمت اس کے قابل ہے. کچھ چیزوں کے لیے (لائیو ویڈیو سٹریمنگ، آن لائن گیمنگ، ڈی این ایس تلاش)، یوزر ڈیٹاگرام پروٹوکول (UDP) کو ترجیح دی جاتی ہے کیونکہ یہ اس اوور ہیڈ کے بغیر پیکٹ منتقل کرتا ہے اور رفتار کی قیمت پر کچھ نقصان برداشت کرتا ہے۔ HTTP/3، جس کا ہم بعد میں احاطہ کریں گے، پروٹوکول کے اوپر بنایا گیا ہے جو UDP کو قابل اعتماد فراہم کرتے ہیں۔

TLS: کنکشن کی خفیہ کاری

جدید ویب پر، زیادہ تر کنکشن سادہ HTTP کے بجائے HTTPS استعمال کرتے ہیں۔ S کا مطلب Secure ہے، اور SSL کے جانشین، ٹرانسپورٹ لیئر سیکیورٹی (TLS) کے ذریعے سیکیورٹی فراہم کی جاتی ہے۔

TLS TCP کنکشن کے اوپر ایک اضافی مصافحہ شامل کرتا ہے۔ TLS مصافحہ کے دوران:

1. کلائنٹ اور سرور اس بات پر متفق ہیں کہ TLS کا کون سا ورژن استعمال کرنا ہے اور کون سے انکرپشن الگورتھم کو سپورٹ کرنا ہے۔

2. سرور ایک ڈیجیٹل سرٹیفکیٹ پیش کرتا ہے (ایک قابل اعتماد سرٹیفکیٹ اتھارٹی کے ذریعہ جاری کیا جاتا ہے)۔

3. کلائنٹ تصدیق کرتا ہے کہ سرٹیفکیٹ درست ہے اور اس سرور سے تعلق رکھتا ہے جس تک پہنچنے کی کوشش کر رہا ہے۔

4. غیر متناسب خفیہ کاری کا استعمال کرتے ہوئے انکرپشن کیز کا تبادلہ کیا جاتا ہے۔

5. اس وقت سے، تمام مواصلات ہم آہنگی خفیہ کاری کے ساتھ خفیہ کردہ ہیں.

TLS ہینڈ شیک تاخیر میں اضافہ کرتا ہے۔ TLS 1.2 کو ایپلیکیشن ڈیٹا کے بہاؤ سے پہلے دو چکر لگانے کی ضرورت ہے۔ TLS 1.3، جو 2018 میں ریلیز ہوا، اسے 1 راؤنڈ ٹرپ تک کم کر دیتا ہے اور واپسی کنکشن کے لیے 0 راؤنڈ ٹرپ دوبارہ شروع کرنے کی بھی حمایت کرتا ہے۔

TCP اور TLS کو سمجھنا ضروری ہے کیونکہ ہم جن پروٹوکول پر بات کرتے ہیں وہ سب سے اوپر چلتے ہیں (حتی کہ HTTP/3، جو بنیادی ٹرانسپورٹ کو تبدیل کرتا ہے)۔ جب لوگ HTTPS کے "اوور ہیڈ” یا کنکشن قائم کرنے کی "لاگت” کے بارے میں بات کرتے ہیں، تو وہ اصل درخواست کے ایک بائٹ کو منتقل کرنے سے پہلے ان مصافحہ پر خرچ کیے گئے وقت اور پیکٹ کے بارے میں بات کرتے ہیں۔

HTTP/1.1: وہ پروٹوکول جس نے ویب بنایا

ایچ ٹی ٹی پی (ہائپر ٹیکسٹ ٹرانسفر پروٹوکول) کو 1991 میں ٹم برنرز لی نے کمپیوٹرز کے درمیان ایچ ٹی ایم ایل دستاویزات کی منتقلی کے لیے ایجاد کیا تھا۔ HTTP/1.0 آسان تھا۔ فی کنکشن ایک درخواست کی جاتی ہے اور پھر کنکشن بند ہوجاتا ہے۔

1997 میں معیاری، HTTP/1.1 نے نمایاں بہتری لائی اور تقریباً دو دہائیوں تک HTTP کا غالب ورژن بن گیا۔ اس نے مستقل کنکشنز (متعدد درخواستوں پر ایک کنکشن کو کھلا رکھنا)، چنکڈ ٹرانسفر انکوڈنگ، اور زیادہ نفیس کیشنگ میکانزم متعارف کرایا۔

HTTP/1.1 درخواستیں کیسے کام کرتی ہیں۔

HTTP درخواستیں ایک مخصوص ساخت کے ساتھ ٹیکسٹ پیغامات ہیں۔

POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...
Accept: application/json
Content-Length: 45
User-Agent: MyApp/2.0

{"name": "John Smith", "email": "john@example.com"}

پہلی لائن درخواست کی لائن ہے۔ یعنی، HTTP طریقہ (POST)، راستہ (/api/users)، اور پروٹوکول ورژن۔

اس کے نیچے ہیڈر ہیں، کلیدی قدر کے جوڑے جو درخواست کے بارے میں میٹا ڈیٹا فراہم کرتے ہیں۔ میزبان، مواد کی قسم، تصدیقی ٹوکن، کلائنٹ کی طرف سے قبول کردہ فارمیٹ، اور جسم کا سائز۔

خالی لائن کے بعد متن آتا ہے۔ یعنی اصل ڈیٹا منتقل کیا جا رہا ہے۔

سرور اس پر کارروائی کرتا ہے اور مندرجہ ذیل جواب دیتا ہے:

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/users/usr_789
Date: Mon, 21 Jul 2026 09:15:00 GMT
Content-Length: 89

{"id": "usr_789", "name": "John Smith", "email": "john@example.com", "created_at": "..."}

جواب میں اسٹیٹس لائن (پروٹوکول ورژن، اسٹیٹس کوڈ، اور وجہ جملہ)، ہیڈر اور باڈی ہے۔

HTTP طریقے اور سیمنٹکس

HTTP/1.1 کئی طریقوں کی وضاحت کرتا ہے، ہر ایک کا ایک مخصوص معنی ہے۔

• حاصل کریں وسائل تلاش کریں۔ GET درخواستوں کے کوئی مضر اثرات نہیں ہونے چاہئیں۔ آپ کو کچھ بھی تخلیق یا ترمیم نہیں کرنا چاہئے۔ یہ محفوظ اور غیرمعمولی ہے، اس لیے اسے کئی بار پکارنے کا وہی اثر ہوتا ہے جیسا کہ اسے ایک بار پکارنا۔

• میل نیا وسیلہ بنانے یا کارروائی کو متحرک کرنے کے لیے ڈیٹا جمع کرائیں۔ یہ نہ تو محفوظ ہے اور نہ ہی کمزور۔ POST کو دو بار کال کرنے سے عام طور پر دو وسائل پیدا ہوتے ہیں۔

• ڈال فراہم کردہ ڈیٹا سے وسائل کو مکمل طور پر بدل دیتا ہے۔ یہ بے حس ہے۔ ایک ہی ڈیٹا کے ساتھ PUT کو دو بار کال کرنے کا اثر ایک بار کال کرنے جیسا ہی ہوتا ہے۔

• جگہ جزوی طور پر ایک وسائل کو اپ ڈیٹ کرتا ہے۔ صرف فراہم کردہ فیلڈز کو تبدیل کیا جائے گا۔

• حذف کریں وسائل کو ہٹا دیں۔ یہ بے حس ہے۔ غیر موجود اشیاء کو حذف کرنا اب بھی ایک کامیابی سمجھا جاتا ہے۔

• سر جی ای ٹی کی طرح، لیکن سرور صرف ہیڈرز واپس کرتا ہے، باڈی نہیں۔ یہ چیک کرنے کے لیے استعمال کیا جاتا ہے کہ آیا کوئی وسیلہ موجود ہے یا پورے مواد کو ڈاؤن لوڈ کیے بغیر اس میں ترمیم کی گئی ہے۔

• اختیارات سرور سے پوچھیں کہ وسائل پر کن طریقوں کی اجازت ہے۔ CORS پری عمل درآمد کی درخواستوں کے لیے استعمال کیا جاتا ہے۔

اسٹیٹس کوڈ

HTTP اسٹیٹس کوڈز تین ہندسوں کے نمبر ہیں جنہیں پانچ زمروں میں گروپ کیا گیا ہے۔

1xx معلومات – سرور کو درخواست موصول ہوئی ہے اور وہ اس پر کارروائی جاری رکھے ہوئے ہے۔ یہ مخصوص استعمال کے معاملات جیسے HTTP اپ گریڈ (ویب ساکٹ کنکشن قائم کرنے کے لیے استعمال کیا جاتا ہے) کے باہر عملی طور پر شاذ و نادر ہی دیکھا جاتا ہے۔

2xx کامیابی – آپ کی درخواست موصول، سمجھی اور قبول کر لی گئی ہے۔

• 200 ٹھیک ہے: معیاری کامیابی کا جواب

• 201 بنایا گیا: ایک نیا وسیلہ بنایا گیا ہے۔

• 204 کوئی مواد نہیں: کامیابی، لیکن واپس کرنے کے لیے کچھ نہیں (عام طور پر حذف کرنا)

3xx ری ڈائریکٹ – آپ کی درخواست کو مکمل کرنے کے لیے اضافی کارروائی کی ضرورت ہے۔

• 301 مستقل طور پر منتقل: وسائل میں مستقل طور پر ایک نیا URL ہے۔

• 302 ملا: عارضی ری ڈائریکٹ

• 304 میں ترمیم نہیں کی گئی: کیشڈ ورژن اب بھی درست ہے (ای ٹیگ کے ساتھ استعمال کیا جاتا ہے)

4xx کلائنٹ کی خرابی۔ – درخواست میں غلط نحو ہے یا اس پر کارروائی نہیں کی جا سکتی۔

• 400 خراب درخواست: درخواست کی شکل غلط ہے۔

• 401 غیر مجاز: توثیق درکار ہے (نام سے قطع نظر، اس کا مطلب ہے کہ آپ مجاز نہیں ہیں)

• 403 ممنوع: آپ کی توثیق شدہ ہے، لیکن آپ کو اس وسائل تک رسائی کی اجازت نہیں ہے۔

• 404 نہیں ملا: وسائل موجود نہیں ہے۔

• 422 ناقابل عمل ہستی: درخواست نحوی طور پر درست ہے، لیکن لفظی طور پر غلط ہے (تصدیق کی غلطیوں کے لیے عام)۔

• 429 بہت زیادہ درخواستیں: شرح کی حد سے تجاوز کر گئی۔

5xx سرور کی خرابی۔ – سرور ایک درست درخواست کو پورا کرنے میں ناکام رہا۔

• 500 اندرونی سرور کی خرابی: سرور کے ساتھ ایک مسئلہ پیش آگیا۔

• 502 خراب گیٹ وے: سرور کو اپ اسٹریم سرور سے غلط جواب موصول ہوا۔

• 503 سروس دستیاب نہیں ہے: سرور عارضی طور پر دستیاب نہیں ہے۔

• 504 گیٹ وے ٹائم آؤٹ: اپ اسٹریم سرور نے وقت پر جواب نہیں دیا۔

HTTP/1.1 میں کیشنگ

HTTP/1.1 کی سب سے طاقتور خصوصیات میں سے ایک اس کا بلٹ ان کیشنگ ماڈل ہے۔ جواب میں ایسے ہیڈر شامل ہو سکتے ہیں جو کلائنٹ اور انٹرمیڈیٹ کیشز کو بتاتے ہیں کہ جواب کو کب تک ذخیرہ کرنا ہے اور کب اسے دوبارہ درست کرنا ہے۔

• Cache-Control: max-age=3600 کلائنٹ کو اس جواب کو 1 گھنٹے کے لیے کیش کرنے کی ہدایت کرتا ہے۔

• Cache-Control: no-cache کلائنٹ کو ہدایت کرتا ہے کہ اسے استعمال کرنے سے پہلے ہمیشہ سرور کے ساتھ کیش شدہ جواب کی دوبارہ تصدیق کرے۔

• Cache-Control: no-store کلائنٹ کو اس جواب کو کیش نہ کرنے کی ہدایت کرتا ہے۔

ETag یہ جواب کا فنگر پرنٹ ہے۔ اگر کلائنٹ فالو اپ کی درخواست کرتا ہے، تو ETag دوبارہ بھیجا جاتا ہے۔ If-None-Match ہیڈر اگر مواد تبدیل نہیں ہوا ہے، تو سرور 304 ناٹ موڈیفائیڈ کے ساتھ جواب دے گا اور بینڈوڈتھ کو بچانے کے لیے کوئی باڈی نہیں ہے۔

Last-Modified یہ اسی طرح کام کرتا ہے۔ کلائنٹ بھیجتا ہے۔ If-Modified-Since سرور چیک کرتا ہے کہ آیا مواد تبدیل ہوا ہے۔

کیشنگ ایک اہم وجہ ہے جس کی وجہ سے HTTP پر REST غالب ہو گیا ہے۔ اچھی طرح سے ڈیزائن کردہ REST APIs کی GET درخواستوں کو CDN سطح پر کیش کیا جا سکتا ہے۔ اس کا مطلب یہ ہے کہ ہزاروں صارفین کو ایک ہی جواب دیا جاتا ہے بغیر کسی درخواست کے اصل سرور تک پہنچے۔

HTTP/1.1 کے مسائل حل نہیں ہو سکتے

HTTP/1.1 نے 20 سالوں سے ویب کی اچھی خدمت کی ہے۔ تاہم، جیسا کہ ویب زیادہ پیچیدہ ہو گیا ہے، ایپلی کیشنز زیادہ متحرک ہو گئی ہیں، اور صارف کی توقعات میں اضافہ ہوا ہے، اس کی تعمیراتی حدود نے کارکردگی میں سنگین رکاوٹیں پیدا کر دی ہیں۔

لائن بلاک کرنے کا سربراہ

HTTP/1.1 ایک ہی کنکشن پر ترتیب وار درخواستوں پر کارروائی کرتا ہے۔ اسی کنکشن پر اگلی درخواست شروع ہونے سے پہلے سرور کو ایک درخواست پر اپنا جواب مکمل کرنا چاہیے۔

Connection 1:
Request 1 (slow database query) -----> [3 seconds] -----> Response 1
Request 2 (fast in-memory read) -----> [waits 3 seconds] -----> Response 2
Request 3 (static file) -----------> [waits 3+ seconds] -----> Response 3

درخواست 2 اور درخواست 3 فوری کارروائیاں ہیں۔ تاہم، وہ درخواست 1 کے مکمل ہونے کا انتظار کر رہے ہیں۔ یہ لائن بلاک کرنے کا سر ہے۔ قطار کا سربراہ اس کے پیچھے ہر چیز کو روکتا ہے۔

براؤزرز نے ایک ہی سرور پر متعدد متوازی TCP کنکشن (عام طور پر چھ) کھول کر اس مسئلے کو حل کیا۔ تاہم، ہر کنکشن کو اپنے TCP ہینڈ شیک اور TLS گفت و شنید کی ضرورت ہوتی ہے، کلائنٹ اور سرور دونوں پر وسائل استعمال کرتے ہیں۔

تمام HTTP/1.1 درخواستیں پورے ہیڈر کو سادہ متن میں بھیجتی ہیں۔ ایک موبائل ایپلیکیشن پر غور کریں جو ایک سیشن کے دوران 50 درخواستیں بھیجتی ہے۔ ہر ایک درخواست میں درج ذیل ہیڈر مکمل بھیجے جاتے ہیں:

Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c3JfMTIzIn0...
Content-Type: application/json
Accept: application/json
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)...

JWT کو لے جانے والا اکیلے اجازت نامے کا ہیڈر 400 سے 600 بائٹس ہو سکتا ہے۔ 50 درخواستوں سے ضرب کرنے پر، آپ کو 20 سے 30 KB ڈیٹا ملتا ہے، بشمول صرف ہیڈرز جو درخواستوں کے درمیان تبدیل نہیں ہوتے ہیں۔

محدود بینڈوڈتھ کے ساتھ 4G موبائل کنکشنز پر، یہ بیکار ہے۔ محدود نیٹ ورک کے ماحول میں 2G کنکشنز پر کارکردگی نمایاں طور پر کم ہو جائے گی۔

کوئی سرور پش نہیں۔

HTTP/1.1 سختی سے درخواست کا جواب ہے۔ سرور اس وقت تک ڈیٹا نہیں بھیج سکتا جب تک کہ کلائنٹ اس کی درخواست نہ کرے۔ اس بنیادی حد کا مطلب ہے کہ سرور فعال طور پر تبدیلیوں کے کلائنٹس کو مطلع نہیں کر سکتا۔

ان ایپلیکیشنز کے لیے جن کو حقیقی وقت میں اپ ڈیٹ کی ضرورت ہوتی ہے، مختصر پولنگ ایک عام حل بن گیا ہے۔ کلائنٹ ہر چند سیکنڈ میں ایک درخواست بھیجتا ہے کہ "کیا کچھ بدل گیا ہے؟” یہ غیر موثر ہے کیونکہ زیادہ تر پولنگ درخواستوں کو "نہیں، کچھ نہیں بدلا” جواب ملتا ہے، بینڈوڈتھ اور سرور کے وسائل کو بغیر کسی مقصد کے استعمال کیا جاتا ہے۔

طویل پولنگ کو بہتر بنایا گیا ہے۔ کلائنٹ ایک درخواست بھیجتا ہے اور سرور درخواست کو اس وقت تک کھلا رکھتا ہے جب تک کہ کچھ تبدیل نہ ہو جائے یا وقت ختم نہ ہو جائے۔ یہ غیر ضروری جوابات کو کم کرتا ہے، لیکن سرور کے وسائل کو استعمال کرتے ہوئے کنکشن غیر معینہ مدت تک کھلے رہنے کا سبب بنتا ہے۔

دونوں HTTP/1.1 کے درخواست کے جواب کے ماڈل کی بنیادی حدود کے لیے حل ہیں۔

کنکشن کا غیر موثر استعمال

نیا TCP کنکشن کھولنے کے لیے تین طرفہ ہینڈ شیک اور TLS ہینڈ شیک کی ضرورت ہوتی ہے۔ اس عمل میں موبائل کنکشن پر 200 سے 500 ملی سیکنڈ لگ سکتے ہیں۔

HTTP/1.1 نے متعدد درخواستوں پر کنکشنز کو دوبارہ استعمال کرنے کے لیے کیپ-ایلیو کنکشن متعارف کرائے، لیکن یہ فیچر صرف جزوی طور پر ہی ہیڈ آف لائن (HOL) بلاک ہونے کی وجہ سے موثر تھا۔ براؤزر معاوضہ کے لیے متعدد کنکشن کھولتے ہیں، لیکن فی ڈومین چھ متوازی کنکشنز پیمانے پر کلائنٹ کی حد اور سرور کے وسائل کا مسئلہ دونوں ہیں۔

HTTP/2: فاؤنڈیشن کی تعمیر نو

گوگل نے HTTP/1.1 کی کارکردگی کی حدود کو دور کرنے کے لیے 2009 میں SPDY (تلفظ "تیز”) کے نام سے ایک پروٹوکول جاری کیا۔ SPDY نے دکھایا ہے کہ بنیادی HTTP سیمنٹکس کو تبدیل کیے بغیر نمایاں بہتری لائی جا سکتی ہے۔ 2015 میں IETF کے ذریعہ معیاری بنایا گیا، HTTP/2 SPDY پر مبنی ہے اور HTTP/1.1 کا جانشین ہے۔

HTTP/2 آپ جو بھیجتے ہیں اسے تبدیل نہیں کرتا ہے۔ ایپلیکیشن ڈویلپر کے نقطہ نظر سے، درخواست میں ابھی بھی طریقے، راستے، ہیڈر اور ایک باڈی ہوتی ہے۔ جواب میں اب بھی اسٹیٹس کوڈ، ہیڈر اور باڈی موجود ہے۔ HTTP/2 میں کیا تبدیلی آتی ہے کہ یہ سب کیسے منتقل ہوتا ہے۔

بائنری فریمنگ: کلیدی تبدیلی

HTTP/1.1 ایک ٹیکسٹ پروٹوکول ہے۔ ہیڈرز، سٹیٹس لائنز، اور طریقہ کار کے نام سبھی ASCII متن ہیں۔ مشین کو اس متن کی تشریح حرف بہ حرف تشریح کرنا ہوگی۔

HTTP/2 ایک بائنری پروٹوکول ہے۔ تمام معلومات کو متن کے بجائے بائنری فریموں میں انکوڈ کیا گیا ہے۔ بائنریز چھوٹی اور مشینوں کے تجزیہ کرنے کے لیے بہت تیز ہیں۔ ہیڈر کے نام کو قدر سے الگ کرنے کے لیے کالون اور نئی لائنوں کی تلاش میں سٹرنگ کو ٹوکنائز کرنے کے بجائے، بائنری پارسر براہ راست میموری سے فکسڈ لینتھ فیلڈز پڑھتا ہے۔

بائنری فریمنگ پرت وہ بنیاد ہے جس پر HTTP/2 کی دیگر تمام خصوصیات بنائی گئی ہیں۔

ملٹی پلیکسنگ: کئی سلسلے، ایک کنکشن

HTTP/2 اسٹریمز کا تصور متعارف کراتا ہے۔ ایک سلسلہ ایک واحد TCP کنکشن کے اندر فریموں کا ایک آزاد، دو طرفہ ترتیب ہے۔ ایک ہی کنکشن پر متعدد سلسلے بیک وقت موجود ہو سکتے ہیں۔

Single TCP connection to api.example.com

Stream 1: GET /user/profile ---------> Response arrives
Stream 2: GET /user/balance ---------> Response arrives
Stream 3: POST /transactions --------> Response arrives
Stream 4: GET /notifications --------> Response arrives

All four streams active simultaneously
No stream waits for any other stream

یہ ملٹی پلیکسنگ ہے۔ بہت سی آزاد درخواستیں اور جوابات ایک ہی کنکشن پر ایک دوسرے سے جڑے ہوئے ہیں۔ HTTP سطح HOL بلاکنگ کو ہٹا دیا گیا ہے۔ سلسلہ 1 پر ایک سست درخواست اسٹریمز 2، 3، یا 4 کو جواب موصول ہونے سے نہیں روکے گی۔

ایک کنکشن چھ متوازی کنکشن کی جگہ لے لیتا ہے۔ TCP مصافحہ اور TLS مذاکرات صرف ایک بار ہوتے ہیں۔ کنکشن اوور ہیڈ ڈرامائی طور پر کم ہو گیا ہے۔

HTTP/2 HPACK نامی الگورتھم کا استعمال کرتے ہوئے ہیڈرز کو کمپریس کرتا ہے، جو خاص طور پر HTTP ہیڈرز کے لیے ڈیزائن کیا گیا ہے۔

HPACK دو طریقوں سے کام کرتا ہے۔ سب سے پہلے، یہ پہلے دیکھے گئے ہیڈروں کی میز کو برقرار رکھتا ہے۔ پچھلی درخواست میں بھیجے گئے ہیڈرز کو دوبارہ منتقل کرنے کے بجائے، ہم ٹیبل کے اندراج کا حوالہ بھیجتے ہیں (سیکڑوں بائٹس کے متن کے بجائے ایک واحد عدد)۔

دوسرا، HPACK نئی ہیڈر اقدار کے لیے ہف مین انکوڈنگ کا استعمال کرتا ہے تاکہ تاروں کے سائز کو کم کیا جا سکے جن کا جدول میں حوالہ نہیں دیا جا سکتا۔

نتیجہ: ایک موبائل ایپلیکیشن جو تمام درخواستوں کے لیے ایک ہی آتھرائزیشن ہیڈر بھیجتی ہے وہ پہلی درخواست کے لیے پورا ہیڈر بھیجے گی اور اس کے بعد آنے والی تمام درخواستوں کے لیے ایک بائٹ یا دو بائٹ حوالہ بھیجے گی۔ اوور ہیڈ جو 500 بائٹس تھا اب 2 بائٹس ہو گیا ہے۔

اس سے ایک سیشن میں 50 درخواستوں پر ہزاروں بائٹس بے کار ہیڈر بھیجنا ختم ہوجاتا ہے۔

سٹریم ترجیح

HTTP/2 کلائنٹس کو اسٹریمز کو ترجیحات تفویض کرنے کی اجازت دیتا ہے۔ ایک ویب صفحہ لوڈ کرنے والا براؤزر اس بات کا اشارہ دے سکتا ہے کہ CSS فائلز (جو کسی بھی چیز کو پیش کرنے کے لیے درکار ہیں) کو تجزیہ اسکرپٹ سے زیادہ ترجیح حاصل ہے (جن کی ابتدائی رینڈرنگ کے لیے ضرورت نہیں ہے)۔ سرور ان ترجیحات کو اس ترتیب کا تعین کرنے کے لیے استعمال کر سکتا ہے کہ جب متعدد اسٹریمز فعال ہوں تو فریم کس میں بھیجے جائیں۔

عملی طور پر، سٹریم کی ترجیحات کو متضاد طور پر لاگو کیا گیا ہے اور اسے HTTP/3 میں دوبارہ ڈیزائن کیا جا رہا ہے۔

سرور دھکا

HTTP/2 سرورز کو درخواستوں کا انتظار کیے بغیر کلائنٹس کو وسائل بھیجنے کی اجازت دیتا ہے۔ جب کوئی براؤزر HTML فائل کی درخواست کرتا ہے، تو سرور فوری طور پر CSS اور JavaScript فائلوں کو دھکیل سکتا ہے جسے وہ جانتا ہے کہ براؤزر کو اگلی ضرورت ہوگی، یہاں تک کہ اس سے پہلے کہ براؤزر نے ایچ ٹی ایم ایل کو پارس کر دیا ہو تاکہ اسے معلوم ہو سکے کہ اسے کیا ضرورت ہے۔

Client: GET /index.html
Server: Here is index.html
Server: (push) Here is styles.css — you will need this
Server: (push) Here is app.js — you will need this too

عملی طور پر، سرور پش کو اس کے نفاذ کی پیچیدگی اور کلائنٹ کے ذریعہ پہلے سے کیش کردہ وسائل کو آگے بڑھانے کے خطرے کی وجہ سے ملا جلا اپنایا گیا ہے۔ HTTP/3 دوبارہ جانچ کر رہا ہے کہ پش کیسے کام کرتا ہے۔

HTTP/2 اور gRPC

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

HTTP/3 اور QUIC: اگلا ارتقاء

HTTP/2 میں بہتری کے باوجود، ایک بنیادی مسئلہ اب بھی باقی ہے۔ یہ TCP ہیڈ آف لائن (HOL) بلاکنگ ہے۔

HTTP/2 نے HTTP سطح پر ہیڈ آف لائن (HOL) بلاکنگ کو ختم کردیا۔ متعدد HTTP/2 سلسلے آزادانہ طور پر آگے بڑھ سکتے ہیں۔ تاہم، یہ تمام سلسلے ایک ہی TCP کنکشن کا اشتراک کرتے ہیں۔ TCP اس بات کی ضمانت دیتا ہے کہ کنکشن میں موجود تمام بائٹس ترتیب سے فراہم کیے گئے ہیں۔ اگر ایک TCP پیکٹ کھو جاتا ہے، تو پورا کنکشن منقطع ہو جاتا ہے جب کہ TCP اس پیکٹ کو دوبارہ منتقل کرتا ہے، یہاں تک کہ گمشدہ پیکٹ سے غیر متعلق اسٹریمز کے لیے۔

HTTP/2 over TCP — packet loss scenario:

Stream 1: data in flight...
Stream 2: data in flight...
Stream 3: packet LOST — TCP retransmission required

Stream 1: STALLED (waiting for TCP retransmission)
Stream 2: STALLED (waiting for TCP retransmission)
Stream 3: retransmission in progress...

دونوں اسٹریمز 1 اور 2 پیکٹ کے نقصان کی وجہ سے مسدود ہیں، جو صرف سٹریم 3 کو متاثر کرتی ہے۔ یہ TCP ہیڈ آف لائن بلاکنگ ہے اور HTTP/2 اسے ہٹا نہیں سکتا کیونکہ یہ TCP پرت کے اوپر کام کرتا ہے۔

QUIC: ایک نیا ٹرانسپورٹ پروٹوکول

گوگل نے اس مسئلے کو حل کرنے کے لیے QUIC (کوئیک UDP انٹرنیٹ کنیکشنز) تیار کیا۔ QUIC ایک نیا ٹرانسپورٹ پروٹوکول ہے جو TCP کے بجائے UDP پر بنایا گیا ہے، اور بہت مفید نئی خصوصیات فراہم کرنے کے لیے ڈیزائن کیا گیا ہے۔

1. HOL بلاکنگ کے بغیر ملٹی پلیکسنگ: QUIC مقامی طور پر اسٹریمز کو سمجھتا ہے۔ اگر ایک QUIC سٹریم میں پیکٹ کا نقصان ہوتا ہے، تو صرف وہی سلسلہ روکا جاتا ہے۔ اسی سلسلے کے دیگر سلسلے آزادانہ طور پر بہتے رہتے ہیں۔

2. بلٹ ان انکرپشن: TLS کے برعکس، جو TCP کے اوپر چلتا ہے، QUIC کے پاس پروٹوکول میں TLS 1.3 شامل ہے۔ نقل و حمل اور حفاظتی تہوں کو مربوط کیا جاتا ہے، جس سے ڈیٹا کے بہاؤ کے لیے درکار راؤنڈ ٹرپس کی تعداد کم ہوتی ہے۔

3. تیز تر کنکشن قائم کریں: ڈیٹا کے بہاؤ سے پہلے ایک نئے QUIC کنکشن کے لیے ایک راؤنڈ ٹرپ درکار ہوتا ہے۔ واپسی کنکشن کے لیے جہاں سیشن ٹکٹ موجود ہے، QUIC صفر راؤنڈ ٹرپ (0-RTT) میں ڈیٹا بھیج سکتا ہے۔

4. کنکشن کی منتقلی: TCP کنکشن کی شناخت سورس آئی پی، سورس پورٹ، ڈیسٹینیشن آئی پی، اور ڈیسٹینیشن پورٹ کے چار ٹوپل سے ہوتی ہے۔ جب ایسی تبدیلی واقع ہوتی ہے (مثال کے طور پر، ایک موبائل ڈیوائس وائی فائی سے سیلولر پر سوئچ کرتا ہے)، TCP کنکشن کھو جاتا ہے اور اسے دوبارہ قائم کرنا ضروری ہے۔ QUIC کنکشنز کی شناخت ایک کنکشن ID کے ذریعے کی جاتی ہے جو نیٹ ورک کی تبدیلیوں کے دوران برقرار رہتی ہے، جو بغیر کسی رکاوٹ کے ہینڈ آف کی اجازت دیتی ہے۔

HTTP/3

HTTP/3 QUIC کے لیے HTTP سیمنٹکس ہے۔ درخواست اور جواب کا ماڈل وہی رہتا ہے۔ ہیڈرز، سٹیٹس کوڈز اور طریقے سب ایک جیسے ہیں۔ نیچے کی نقل و حمل TCP کے بجائے QUIC ہے۔

HTTP/3 خاص طور پر درج ذیل معاملات کو متاثر کرتا ہے:

1. موبائل نیٹ ورک پیکٹ کا نقصان زیادہ عام ہے اور آلات اکثر نیٹ ورکس کے درمیان سوئچ کرتے ہیں۔

2. ہائی لیٹینسی کنکشن ہینڈ شیک راؤنڈ ٹرپس کی تعداد کو کم کرکے بامعنی وقت بچایا جاتا ہے۔

3. متعدد سمورتی سلسلے کے ساتھ ایپلی کیشنز TCP ہیڈ آف لائن بلاکنگ یہاں اصل رکاوٹ تھی۔

2026 سے، HTTP/3 کو بڑے براؤزرز، CDNs، اور بیک اینڈ سرورز کی بڑھتی ہوئی تعداد کے ذریعے سپورٹ کیا جائے گا۔ اپنانے میں اضافہ جاری ہے۔

ڈیٹا فارمیٹ: معلومات کو کیسے انکوڈ کیا جاتا ہے۔

اس سے قطع نظر کہ کون سا پروٹوکول ڈیٹا رکھتا ہے، سسٹمز کو اس بات پر متفق ہونا چاہیے کہ ڈیٹا کو کیسے انکوڈ کیا جاتا ہے۔ API کمیونیکیشن کے لیے سب سے اہم فارمیٹس JSON اور Protocol Buffers ہیں۔

JSON: عام مقصد کی زبان

JavaScript آبجیکٹ نوٹیشن (JSON) JavaScript نحو سے ماخوذ ہے اور اسٹینڈ اکیلے ڈیٹا فارمیٹ کے طور پر فارمیٹ کیا گیا ہے۔ ڈیزائن کا فلسفہ انسانی پڑھنے کی اہلیت اور سادگی ہے۔

JSON آبجیکٹ گھوبگھرالی منحنی خطوط وحدانی میں بند کلیدی قدر کے جوڑوں کا مجموعہ ہے۔ چابیاں ہمیشہ تار ہوتی ہیں۔ قدریں سٹرنگز، نمبرز، بولین، نال، اری یا دیگر اشیاء ہو سکتی ہیں۔

{
  "id": "usr_001",
  "name": "John Smith",
  "age": 28,
  "is_verified": true,
  "scores": [98, 87, 92],
  "address": {
    "city": "Lagos",
    "country": "Nigeria"
  }
}

JSON کئی وجوہات کی بنا پر غالب API ڈیٹا فارمیٹ بن گیا ہے۔ انسانی پڑھنے کے قابل۔ ڈویلپرز اپنے براؤزر کے ڈویلپر ٹولز میں JSON جواب کو دیکھ اور سمجھ سکتے ہیں۔ یہ تقریبا کسی بھی پروگرامنگ زبان میں ڈیٹا ڈھانچے کو قدرتی طور پر نقشہ بناتا ہے۔ کسی خاص ٹولز یا اسکیما کی تعریف کی ضرورت نہیں ہے۔ یہ لچکدار بھی ہے۔ آپ موجودہ کلائنٹس کو توڑے بغیر فیلڈز کو شامل یا ہٹا سکتے ہیں۔

JSON کے ساختی اخراجات

JSON کا انسانی پڑھنے کے قابل ڈیزائن بڑے پیمانے پر ساختی اخراجات کے ساتھ آتا ہے۔

تمام فیلڈ کے نام تار ہیں جو ہر ایک جواب میں پورے نیٹ ورک میں سفر کرتے ہیں۔ اوپر کی مثال میں، سٹرنگ ہے "is_verified"، "address"، "country" یہ ڈیٹا نہیں ہے۔ ڈیٹا کے لیے ایک لیبل۔ بائٹس استعمال کی جاتی ہیں، ٹوکنائز اور پارس ہونا ضروری ہے، اور ہر صارف کے ہر جواب کے لیے دہرایا جاتا ہے۔

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

اندرونی APIs والے فنٹیک پلیٹ فارمز کے لیے جو 1000-فیلڈ جوابات واپس کرتے ہیں اور درجنوں داخلی خدمات میں روزانہ لاکھوں بار بلائے جاتے ہیں، JSON کے وربوز ڈسپلے اور پارسنگ اوور ہیڈ کی مجموعی لاگت بینڈوتھ بلز اور سرور CPU وقت میں قابل پیمائش ہو جاتی ہے۔

JSON کے پاس نیٹ ورک کی سطح پر رسمی اسکیما بھی نہیں ہے۔ خود JSON فارمیٹ میں کچھ بھی نہیں ہے جو بیک اینڈ کی تبدیلیوں کو روکتا ہے۔ "account_balance" کو "balance". تبدیلیاں کامیابی سے مرتب ہوئیں۔ سرور تعینات ہے۔ منحصر کلائنٹ "account_balance" یہ رن ٹائم پر خود بخود رک جائے گا۔

XML: پیشرو

JSON سے پہلے، ایکسٹینسیبل مارک اپ لینگویج (XML) ویب سروسز کے لیے بنیادی ڈیٹا فارمیٹ تھا (SOAP، REST کے پیشرو میں استعمال کیا جاتا ہے)۔ XML JSON سے زیادہ لفظی ہے اور تمام اقدار کو کھولنے اور بند کرنے والے ٹیگز میں گروپ کرتا ہے۔

  usr_001
  John Smith
  28
  true

XML کے اپنے فوائد ہیں۔ اس کا مطلب ہے کہ یہ اسکیموں (XSD)، نام کی جگہوں، اور پیچیدہ دستاویز کے ڈھانچے کو سپورٹ کرتا ہے۔ یہ اب بھی انٹرپرائز سسٹمز، دستاویز فارمیٹس (DOCX، SVG، RSS) اور کنفیگریشن فائلوں میں استعمال ہوتا ہے۔ لیکن جب API مواصلات کی بات آتی ہے تو، JSON کی سادگی جیت جاتی ہے۔

باقی: وہ فن تعمیر جو پوری دنیا کو اپنی لپیٹ میں لے لیتا ہے۔

REST (نمائندہ ریاست کی منتقلی) کی تعریف Roy Fielding نے 2000 میں اپنے ڈاکٹریٹ کے مقالے میں کی تھی۔ فیلڈنگ HTTP تفصیلات کے بنیادی مصنفین میں سے ایک ہے، اور REST ان کے اس تجزیہ سے پیدا ہوا ہے جس نے HTTP کو تعمیراتی طور پر کامیاب بنایا۔

REST کوئی پروٹوکول نہیں ہے۔ یہ ایک فن تعمیر کا انداز ہے۔ رکاوٹوں کا ایک مجموعہ جو تقسیم شدہ نظاموں پر لاگو ہونے پر مطلوبہ خصوصیات پیدا کرتا ہے، بشمول اسکیل ایبلٹی، سادگی، اور تبدیلی۔

6 آرام کی پابندیاں

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

1. کلائنٹ سرور: کلائنٹ اور سرور الگ الگ خدشات ہیں۔ کلائنٹ یوزر انٹرفیس کا انتظام کرتا ہے۔ سرورز ڈیٹا اسٹوریج اور کاروباری منطق کا انتظام کرتے ہیں۔ وہ آزادانہ طور پر تیار ہوتے ہیں۔ یہ علیحدگی ہر ایک کو دوسرے کو متاثر کیے بغیر توسیع اور تبدیل کرنے کی اجازت دیتی ہے۔

2. بے وطنی: کلائنٹ کی طرف سے سرور سے ہر درخواست میں درخواست کو سمجھنے اور اس پر کارروائی کرنے کے لیے ضروری تمام معلومات پر مشتمل ہونا ضروری ہے۔ سرور درخواستوں کے درمیان سیشن کی حالت کو محفوظ نہیں کرتا ہے۔ جب ایک کلائنٹ کو تصدیق کرنے کی ضرورت ہوتی ہے، توثیق کی معلومات (عام طور پر ایک ٹوکن) ہر درخواست کے ساتھ سفر کرتی ہے۔

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

3. قابل ذخیرہ: جواب کو کیش ایبل یا نان کیش ایبل کے طور پر بیان کیا جانا چاہیے۔ اگر جواب کو کیش کیا جا سکتا ہے تو، کلائنٹ اور درمیانی درجے (CDN، ریورس پراکسی) سرور تک پہنچنے کے بغیر جواب کو ذخیرہ اور دوبارہ استعمال کر سکتے ہیں۔

کیشنگ REST کی سب سے طاقتور خصوصیات میں سے ایک ہے۔ ایک اچھی طرح سے ڈیزائن کیا گیا REST API CDN کیشے سے لاکھوں ایک جیسی GET درخواستوں کو سنبھال سکتا ہے، ان میں سے صرف ایک چھوٹا سا حصہ اصل سرور تک پہنچتا ہے۔

4. متحد انٹرفیس: کلائنٹ اور سرور کے درمیان انٹرفیس معیاری ہے. وسائل کی شناخت URIs سے ہوتی ہے۔ وسائل کو نمائندگی کے ذریعے استعمال کیا جاتا ہے۔ پیغام خود وضاحتی ہے۔ یہی یکسانیت REST APIs کو عالمی طور پر قابل رسائی بناتی ہے۔ کسی بھی زبان میں ڈویلپر معیاری HTTP ٹولز کا استعمال کرتے ہوئے REST APIs کو کال کر سکتے ہیں۔

5. ٹائرڈ سسٹم: کلائنٹ کو یہ جاننے کی ضرورت نہیں ہے کہ آیا یہ براہ راست سرور سے منسلک ہے یا کسی بیچوان سے (لوڈ بیلنسر، سی ڈی این، API گیٹ وے، کیشنگ پراکسی)۔ ہر پرت صرف اس پرت کو دیکھتی ہے جس کے ساتھ وہ تعامل کرتی ہے۔ یہ شفاف اسکیلنگ اور سیکیورٹی کو قابل بناتا ہے۔

6. حسب ضرورت کوڈ (اختیاری): سرور ایگزیکیوٹیبل کوڈ (جاوا اسکرپٹ) بھیج کر کلائنٹ کی فعالیت کو بڑھا سکتا ہے۔ یہ واحد اختیاری رکاوٹ ہے اور یہ بنیادی ہے کہ براؤزر کیسے کام کرتے ہیں، لیکن API ڈیزائن کے ساتھ اس کا بہت کم تعلق ہے۔

وسائل اور URIs

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

وسائل کی شناخت یونیفارم ریسورس آئیڈینٹیفائر (URI) سے ہوتی ہے۔ URI اس بات کی نشاندہی کرتا ہے کہ وسیلہ کیا ہے، نہ کہ اس کے ساتھ کیا کرنا ہے۔ HTTP طریقے ایکسپریس آپریشنز۔

GET    /users           — retrieve all users
GET    /users/123       — retrieve user 123
POST   /users           — create a new user
PUT    /users/123       — replace user 123 entirely
PATCH  /users/123       — partially update user 123
DELETE /users/123       — delete user 123

GET    /users/123/orders        — orders belonging to user 123
POST   /users/123/orders        — create an order for user 123
GET    /users/123/orders/456    — order 456 belonging to user 123

URI ڈھانچہ ایک درجہ بندی بناتا ہے جو وسائل کے درمیان تعلقات کی عکاسی کرتا ہے۔ یہ API کو قابل پیشن گوئی بناتا ہے۔ ڈویلپرز جو وسائل کے ماڈل کو سمجھتے ہیں صحیح URI کا اندازہ لگا سکتے ہیں۔

کیوں REST جیت گیا۔

REST ان وجوہات کی بنا پر ویب APIs کے لیے غالب آرکیٹیکچرل اسٹائل بن گیا ہے جو اس کے تکنیکی فوائد سے بالاتر ہیں۔

عالمگیر رسائی: کوئی بھی ڈیوائس، زبان، یا فریم ورک جو HTTP درخواستیں کر سکتا ہے REST API کو کال کر سکتا ہے۔ کسی خاص کلائنٹ لائبریریوں کی ضرورت نہیں ہے۔

HTTP ترتیب: REST HTTP کے موجودہ انفراسٹرکچر کا فائدہ اٹھاتا ہے۔ CDN کیشنگ مفت میں کام کرتی ہے۔ لوڈ بیلنسر HTTP کو سمجھتا ہے۔ مانیٹرنگ ٹول HTTP استعمال کرتا ہے۔ پورا ماحولیاتی نظام HTTP سیمنٹکس کے ارد گرد بنایا گیا ہے۔

سادگی: REST APIs کو کم سے کم ٹولز کا استعمال کرتے ہوئے ڈیزائن، دستاویزی اور استعمال کیا جا سکتا ہے۔ ڈویلپرز براؤزر کا استعمال کرتے ہوئے اختتامی نقطہ کی جانچ کر سکتے ہیں یا: curl فوری طور پر

ڈویلپر کا تجربہ: JSON اوور HTTP وہ چیز ہے جس کو ہر ویب ڈویلپر پہلے ہی سمجھتا ہے۔ سیکھنے کا وکر بنیادی طور پر صفر ہے۔

ماحولیاتی نظام کی پختگی: OpenAPI/Swagger معیاری دستاویزات فراہم کرتا ہے۔ پوسٹ مین جانچ فراہم کرتا ہے۔ تمام پروگرامنگ زبانوں میں طاقتور HTTP کلائنٹ لائبریریاں ہیں۔

REST کی حدود

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

زیادہ حاصل کرنا: اپنی ضرورت سے زیادہ حاصل کرنا۔

REST اینڈ پوائنٹس ایک مقررہ فارمیٹ میں ڈیٹا واپس کرتے ہیں۔ کہ /users/123 اختتامی نقطہ صارف کا پورا آبجیکٹ واپس کرتا ہے، بشمول نام، ای میل، فون، پتہ، ترجیحات، اکاؤنٹ کی حیثیت، اور 30 ​​دیگر فیلڈز۔

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

محدود موبائل کنکشنز پر، یہ اوور فیچ نہ صرف ناکارہ ہے، بلکہ یہ صارف کے تجربے کی ایک قابل پیمائش تنزلی ہے۔

انڈر فیچنگ: ایک وقت کافی نہیں ہے۔

مخالف مسئلہ بھی اتنا ہی عام ہے۔ اسکرین کو متعدد وسائل سے ڈیٹا کی ضرورت ہوتی ہے، بشمول صارف پروفائل، حالیہ آرڈرز، نوٹیفکیشن شمار، اور اکاؤنٹ بیلنس۔

REST APIs عام طور پر اسے ایک علیحدہ اختتامی نقطہ کے طور پر ماڈل کرتے ہیں۔ اس اسکرین کو لوڈ کرنے کے لیے چار علیحدہ HTTP درخواستیں درکار ہیں، ہر ایک کی اپنی راؤنڈ ٹرپ لیٹنسی کے ساتھ۔

GET /users/123         → profile data
GET /users/123/orders  → orders data
GET /notifications?user=123 → notification count
GET /accounts/123/balance   → balance data

لگاتار چار چکر لگائے۔ 200ms لیٹنسی کنکشن پر، اسکرین کو مکمل طور پر رینڈر ہونے میں 800ms نیٹ ورک کا وقت لگتا ہے۔

N+1 مسئلہ

انڈر فیچنگ کا ایک عام تغیر: آپ کو وسائل کی فہرست حاصل کرنی ہوگی اور پھر فہرست میں موجود ہر آئٹم کے لیے اضافی ڈیٹا حاصل کرنا ہوگا۔

GET /orders            → returns 20 orders (each with a user_id)
GET /users/1           → user for order 1
GET /users/2           → user for order 2
...
GET /users/20          → user for order 20

ایک اسکرین کو لوڈ کرنے میں 21 درخواستیں لگتی ہیں۔ یہ پیٹرن REST APIs میں مستقل طور پر ظاہر ہوتا ہے اور اسے مختلف طریقوں سے ہینڈل کیا جاتا ہے، بشمول جواب میں نیسٹڈ ڈیٹا شامل کرنا، متعلقہ وسائل کو بڑھانے کے لیے استفسار کے پیرامیٹرز کو شامل کرنا، اور مخصوص اسکرینوں کے لیے خاص طور پر بنائے گئے اینڈ پوائنٹس بنانا۔

یہ تمام حل تناؤ پیدا کرتے ہیں۔ APIs کم عام ہو جاتے ہیں کیونکہ وہ مخصوص کلائنٹ کی ضروریات کے لیے موزوں ہوتے ہیں۔

کوئی مقامی ریئل ٹائم سپورٹ نہیں ہے۔

REST درخواست کا جواب ہے۔ کلائنٹ تمام تعاملات شروع کرتا ہے۔ سرور ڈیٹا کو فعال طور پر آگے نہیں بڑھا سکتا۔

ریئل ٹائم فیچرز جیسے ریئل ٹائم اطلاعات، تعاون پر مبنی ایڈیٹنگ، اور اسٹریمنگ ڈیٹا کے لیے پولنگ (ناکارہ)، لمبی پولنگ (پیچیدہ) یا REST APIs کے ساتھ شامل کردہ علیحدہ ریئل ٹائم ٹیکنالوجیز کی ضرورت ہوتی ہے۔

دستاویز کے بہاؤ کا مسئلہ

REST API معاہدہ دستاویزات میں ہے۔ HTTP پروٹوکول میں کوئی بھی چیز دستاویزات کو API کے حقیقی رویے کی درست عکاسی کرنے پر مجبور نہیں کرتی ہے۔ جیسے جیسے APIs تیار ہوتے ہیں، دستاویزات پیچھے رہ جاتی ہیں۔ فیلڈز کا نام تبدیل کر دیا جاتا ہے، اقسام کو تبدیل کر دیا جاتا ہے، اور اختتامی پوائنٹس کو فرسودہ کر دیا جاتا ہے۔ ایک کلائنٹ جو پرانی دستاویز میں خلل کے لیے بنایا گیا ہے۔

یہ کوئی نظریاتی مسئلہ نہیں ہے۔ یہ انجینئرنگ ٹیموں کے لیے روزانہ کی حقیقت ہے جو بیک اینڈ اور فرنٹ اینڈ مختلف شرحوں پر تیار ہوتی ہیں۔

گراف کیو ایل: کلائنٹ کو فیصلہ کرنے دیں۔

GraphQL کو فیس بک میں 2012 سے تیار کیا گیا ہے اور اسے 2015 میں اوپن سورس کے طور پر جاری کیا گیا تھا۔ فیس بک نے اسے ایک مخصوص مسئلے کو حل کرنے کے لیے بنایا تھا۔ اس کا مطلب یہ تھا کہ موبائل ایپس کو REST APIs سے پیچیدہ، باہم منسلک سماجی ڈیٹا کھینچنا پڑا، جس کے نتیجے میں اوور فیچنگ اور ایک سے زیادہ راؤنڈ ٹرپس، موبائل ڈیوائسز پر کارکردگی کو کم کرنے کا باعث بنے۔

گراف کیو ایل کی بنیادی بصیرت سادہ اور بنیاد پرست ہے۔ سرور کو یہ فیصلہ کرنے کی بجائے کہ کون سا ڈیٹا واپس کرنا ہے، کلائنٹ کو بالکل واضح کرنے دیں کہ اسے کس چیز کی ضرورت ہے۔

استفسار کی زبان

گراف کیو ایل APIs کے لیے استفسار کی زبان ہے اور ان سوالات کو انجام دینے کے لیے ایک رن ٹائم ہے۔ مختلف ڈیٹا کے لیے مختلف اینڈ پوائنٹ کو کال کرنے کے بجائے، تمام گراف کیو ایل کی درخواستیں ایک ہی اینڈ پوائنٹ پر جاتی ہیں (عام طور پر /graphql) ایک سوال شامل کریں جو بالکل وہی ڈیٹا بیان کرتا ہے جس کی آپ کو ضرورت ہے۔

صارف پروفائل اسکرین کے لیے گراف کیو ایل استفسار:

query UserProfile {
  user(id: "usr_123") {
    name
    avatarUrl
    recentOrders(limit: 3) {
      id
      total
      status
      createdAt
    }
    notificationCount
  }
}

جواب میں بالکل وہی فیلڈز شامل ہیں جن کی درخواست کی گئی ہے۔ مزید کچھ نہیں۔ صرف اس وقت جب کلائنٹ کو اس کی ضرورت ہو۔ name اور avatarUrlصرف ان دو شعبوں کی درخواست کی گئی ہے۔ جواب میں صرف دو فیلڈز ہیں۔

تغیرات اور سبسکرپشنز

گراف کیو ایل کے تین قسم کے آپریشن ہیں:

1. استفسار ڈیٹا حاصل کریں۔ یہ GET درخواست کے برابر گراف کیو ایل ہے۔

2. اتپریورتن ڈیٹا میں ترمیم کریں: وسائل بنائیں، اپ ڈیٹ کریں یا حذف کریں۔ یہ GraphQL میں POST، PUT، PATCH، اور DELETE کے برابر ہے۔

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

سکیما

ہر گراف کیو ایل API کی وضاحت اسکیما ڈیفینیشن لینگویج (SDL) میں لکھی گئی اسکیما سے ہوتی ہے۔ اسکیما API کے ذریعہ تعاون یافتہ تمام اقسام، سوالات، تبدیلیوں اور سبسکرپشنز کا اعلان کرتا ہے۔

type User {
  id: ID!
  name: String!
  email: String!
  orders: [Order!]!
  notificationCount: Int!
}

type Order {
  id: ID!
  total: Float!
  status: OrderStatus!
  createdAt: String!
}

enum OrderStatus {
  PENDING
  PROCESSING
  SHIPPED
  DELIVERED
}

type Query {
  user(id: ID!): User
  orders(userId: ID!, limit: Int): [Order!]!
}

type Mutation {
  createOrder(userId: ID!, items: [OrderItemInput!]!): Order!
}

اسکیموں کا معائنہ کیا جا سکتا ہے۔ کلائنٹ دستیاب اقسام اور آپریشنز کو دریافت کرنے کے لیے خود اسکیما سے استفسار کر سکتے ہیں۔ یہ آپ کو ایک طاقتور ٹول فراہم کرتا ہے۔ GraphQL IDE سوالات کو خود بخود مکمل کر سکتا ہے، بھیجنے سے پہلے اسکیما کے خلاف تصدیق کر سکتا ہے، اور دستاویزات کو ان لائن ظاہر کر سکتا ہے۔

جہاں گراف کیو ایل جیتتا ہے۔

درست ڈیٹا حاصل کریں: گاہک بالکل وہی مانگتے ہیں جس کی انہیں ضرورت ہے۔ اوور فیچنگ کو ڈیزائن کے ذریعے ختم کیا جاتا ہے۔

پیچیدہ ڈیٹا کے لیے، ایک ہی راؤنڈ ٹرپ: ایک ہی درخواست میں متعدد وسائل سے ڈیٹا حاصل کریں۔ N+1 کا مسئلہ کلائنٹ کو متعدد درخواستیں کرنے کی ضرورت کے بجائے استفسار کی سطح پر حل کیا جاتا ہے۔

سختی سے ٹائپ شدہ اسکیما: اسکیما ایک معاہدہ ہے۔ کلائنٹ تعمیراتی وقت پر سوالات کی توثیق کر سکتے ہیں۔ تعیناتی سے پہلے قسم کی مماثلتوں کا پتہ چل جاتا ہے۔

فرنٹ اینڈ چستی: فرنٹ اینڈ ٹیمیں بیک اینڈ ٹیموں سے نئے اینڈ پوائنٹس بنانے کے لیے کہے بغیر اپنے ڈیٹا کی ضروریات کو تیار کر سکتی ہیں۔ نئی اسکرینیں، ڈیٹا کے مجموعے، اور خصوصیات سبھی نئے سوالات لکھ کر سنبھالے جاتے ہیں۔

اعلی ٹولنگ: گرافی کیو ایل اور اپولو اسٹوڈیو انٹرایکٹو اسکیما ایکسپلوریشن، استفسار کی تعمیر، اور کارکردگی کا تجزیہ فراہم کرتے ہیں۔

جہاں گراف کیو ایل جدوجہد کرتا ہے۔

سوال کی پیچیدگی: بدنیتی پر مبنی یا ناقص تحریری سوالات اوور لیپنگ ڈیٹا کی بڑی مقدار کی درخواست کر سکتے ہیں۔ تمام صارفین، ہر صارف کے آرڈرز، ہر آرڈر کے آئٹمز، اور ہر آئٹم کے پروڈکٹ کی تفصیلات کو بازیافت کرنے والے سوالات سرور کے کریش ہونے کا سبب بن سکتے ہیں۔

REST اینڈ پوائنٹس کو انفرادی طور پر بہتر بنایا جا سکتا ہے۔ گراف کیو ایل کو آپ کے سرورز کی حفاظت کے لیے استفسار کی پیچیدگی کے تجزیہ، گہرائی کو محدود کرنے، اور شرح کو محدود کرنے کی ضرورت ہے۔

کیشنگ زیادہ مشکل ہے۔ REST GET کی درخواستیں HTTP سطح پر بطور ڈیفالٹ کیش ایبل ہیں۔ گراف کیو ایل کے تمام سوالات معیاری HTTP کیچنگ کو توڑتے ہوئے، ایک ہی اختتامی نقطہ پر POST کی درخواستیں کرتے ہیں۔ کلائنٹس کو اپنی کیشنگ کو لاگو کرنا چاہیے (اپولو کلائنٹ ایسا کرتا ہے)، لیکن CDN-سطح کی کیشنگ فطری طور پر متحرک سوالات کے لیے دستیاب نہیں ہے۔

سادہ، زیادہ انجنیئر API: اگر آپ کا API ایک سادہ CRUD آپریشن ہے جس میں ڈیٹا کے کوئی پیچیدہ رشتے نہیں ہیں اور کوئی موبائل کلائنٹس جن میں جارحانہ ڈیٹا کی رکاوٹیں نہیں ہیں، تو GraphQL کے سیٹ اپ کے اضافی اخراجات فوائد سے کہیں زیادہ ہیں۔

پیمانے پر حقیقی وقت پیچیدہ ہے۔ گراف کیو ایل سبسکرپشنز کام کرتی ہیں، لیکن ہزاروں کنکرنٹ سبسکرائبرز کے لیے WebSocket کنکشنز کو اسکیل کرنا بنیادی ڈھانچہ بہت زیادہ ہے اور اس کے لیے محتاط فن تعمیر کی ضرورت ہے۔

خرابی سے نمٹنے کا عمل غیر معیاری ہے۔ GraphQL کی درخواستیں جزوی طور پر کامیاب ہو سکتی ہیں۔ کچھ فیلڈز کی کامیابی کے ساتھ تصدیق ہو جاتی ہے، جبکہ دیگر ناکام ہو جاتی ہیں۔ جواب میں ڈیٹا اور غلطیاں دونوں شامل ہیں۔ اس کو صحیح طریقے سے ہینڈل کرنے کے لیے سادہ HTTP اسٹیٹس کوڈز کے مقابلے میں زیادہ باریک غلطی سے نمٹنے والی منطق کی ضرورت ہوتی ہے۔

WebSocket: جب HTTP کافی نہیں ہے۔

HTTP تمام ورژنز میں بطور ڈیفالٹ درخواست کا جواب ہے۔ گاہک پہلے بولتے ہیں۔ سرور جواب دیتا ہے۔ بات چیت ختم ہو جاتی ہے۔ یہاں تک کہ HTTP/2 کے سرور پش کے ساتھ، کلائنٹ ہر نیا تبادلہ شروع کرتا ہے۔

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

ان صورتوں میں، WebSockets بنیادی طور پر مختلف مواصلاتی ماڈل فراہم کرتے ہیں۔

ویب ساکٹ ہینڈ شیک

ایک WebSocket کنکشن ایک HTTP درخواست کے طور پر شروع کیا جاتا ہے اور پھر WebSocket کنکشن میں اپ گریڈ کیا جاتا ہے۔ اس اپ گریڈ میکانزم کا مطلب ہے کہ WebSockets آپ کے موجودہ HTTP انفراسٹرکچر (فائر والز، پراکسی، لوڈ بیلنسرز) پر بغیر کسی خاص ترتیب کے کام کریں گے۔

اپ گریڈ کی درخواست:

GET /chat HTTP/1.1
Host: api.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

سرور اپ گریڈ کی تصدیق کرتا ہے۔

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

اسٹیٹس کوڈ 101 کا مطلب ہے "پروٹوکول کی منتقلی”۔ اس مقام سے، HTTP کنکشنز کو WebSocket کنکشنز سے بدل دیا جاتا ہے۔ پروٹوکول بدل گیا ہے۔ HTTP ہیڈر، اسٹیٹس کوڈ، اور طریقے اب لاگو نہیں ہوتے ہیں۔

مکمل ڈوپلیکس، مسلسل مواصلات

WebSocket کنکشن اس طرح لگتا ہے:

• مکمل ڈوپلیکس: کلائنٹ اور سرور دوسرے کے ختم ہونے کا انتظار کیے بغیر کسی بھی وقت ایک ساتھ پیغامات بھیج سکتے ہیں۔

• مستقل: کنکشن اس وقت تک کھلا رہتا ہے جب تک کہ کوئی بھی فریق اسے واضح طور پر بند نہ کر دے یا نیٹ ورک کی بندش واقع نہ ہو جائے۔

• کم اوور ہیڈ: ایک بار قائم ہونے کے بعد، WebSocket پیغامات میں HTTP کے مقابلے میں کم سے کم فریمنگ اوور ہیڈ ہوتی ہے۔ ایک چھوٹے WebSocket پیغام میں ممکنہ طور پر سینکڑوں بائٹس HTTP ہیڈر ہو سکتے ہیں، جبکہ اوور ہیڈ صرف 2 سے 10 بائٹس ہو سکتا ہے۔

WebSocket connection open

Client: "Hello, I'm user 123"
Server: "Welcome, user 123"
Server: "User 456 just sent you a message: Hey!"
Client: "Thanks, here's my reply: Hi there!"
Server: "New notification: your payment was confirmed"
Client: "Great, show me my balance"
Server: "Your balance is NGN 500,000"
Server: "Another notification: transfer from user 789 received"

[Both sides communicate freely, at any time, simultaneously]

جہاں WebSockets جیتتے ہیں۔

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

کم تاخیر کا پیغام رسانی: ایک بار کنکشن قائم ہوجانے کے بعد، پیغام کے راؤنڈ ٹرپ کے اوقات سنگل ہندسوں کے ملی سیکنڈ میں ہوسکتے ہیں اور یہ صرف نیٹ ورک لیٹنسی سے محدود ہوتے ہیں، کنکشن سیٹ اپ اوور ہیڈ سے نہیں۔

مقامی براؤزر سپورٹ: WebSocket API تمام جدید براؤزرز میں بنایا گیا ہے۔ مقامی لنکنگ کے لیے کسی لائبریری کی ضرورت نہیں ہے۔

کلائنٹ کا واقعہ سے چلنے والا فن تعمیر: WebSocket واقعات (پیغام، بند، غلطی) قدرتی طور پر ایونٹ پر مبنی کلائنٹ کوڈ کا نقشہ بناتے ہیں۔

جہاں WebSockets جدوجہد کرتے ہیں۔

ریاستی رابطے: ہر WebSocket کنکشن کو ایک مخصوص سرور مثال کے ذریعہ برقرار رکھا جانا چاہئے۔ افقی طور پر اسکیلنگ کرتے وقت، سرور A سے منسلک کلائنٹس سرور B سے مشترکہ اشاعت/سبسکرائب پرت (جیسے Redis) کے بغیر پیغامات وصول نہیں کر سکتے ہیں جس پر سرور کی تمام مثالیں شائع اور سبسکرائب کرتی ہیں۔ اس کے نتیجے میں بنیادی ڈھانچے میں پیچیدگی پیدا ہوئی ہے۔

کوئی بلٹ ان درخواست جوابی تعلق نہیں: WebSocket ایک پیغام کا سلسلہ ہے۔ جب آپ کوئی پیغام بھیجتے ہیں اور جواب کی توقع کرتے ہیں، تو آپس میں رابطہ کرنے کے لیے کوئی بلٹ ان میکانزم نہیں ہوتا ہے کہ کون سا جواب کس درخواست سے مطابقت رکھتا ہے۔ یہ آپ کو خود بنانا ہے۔

کوئی اسکیما یا معاہدہ نہیں: WebSockets خام متن یا بائنری بھیجتے ہیں۔ پیغام کی شکل مکمل طور پر ایپلی کیشن سے متعین ہے۔ WebSockets پر بات چیت کرنے والے دو سسٹمز کو کاغذ پر آؤٹ آف بینڈ میسج فارمیٹ پر متفق ہونا چاہیے، اور کنکشن کی سطح پر اسے نافذ کرنے کا کوئی طریقہ نہیں ہے۔

فائر وال اور پراکسی مسائل: کچھ کارپوریٹ نیٹ ورکس اور پرانے پراکسیز HTTP اپ گریڈ میکانزم کو صحیح طریقے سے سپورٹ نہیں کرتے ہیں، جس کی وجہ سے WebSocket کنکشن ختم ہو جاتے ہیں۔ یہ پہلے سے کم عام ہے، لیکن یہ اب بھی کارپوریٹ ماحول میں ہوتا ہے۔

دوبارہ کنکشنز کو دستی طور پر ہینڈل کیا جانا چاہیے۔ نیٹ ورک کی عدم استحکام کی وجہ سے WebSocket کنکشن ختم ہو سکتے ہیں۔ ایپلیکیشن کو دوبارہ کنکشن کی منطق کو لاگو کرنا چاہیے، بشمول ریاستی انتظام کے پورے ری کنکشن کے دوران۔

سرور سے بھیجے گئے واقعات: ایک آسان ریئل ٹائم آپشن

REST کے خالص درخواست کے جواب اور WebSockets کے مکمل دو طرفہ مواصلات کے درمیان، ایک درمیانی آپشن ہے جسے زیادہ تر ڈویلپر نظر انداز کرتے ہیں: Server Sent Events (SSE)۔

SSE ایک طرفہ مسلسل کنکشن قائم کرتا ہے۔ یعنی سرور ایک باقاعدہ HTTP کنکشن کے ذریعے کلائنٹ کو ڈیٹا بھیجتا ہے، اور کلائنٹ اسے وصول کرتا ہے۔ کلائنٹ اسی کنکشن پر دوبارہ ڈیٹا نہیں بھیج سکتا۔

SSE کیسے کام کرتا ہے۔

کلائنٹ استعمال کرتے ہوئے ایک معیاری HTTP GET درخواست کرتا ہے: Accept: text/event-stream ہیڈر:

GET /notifications HTTP/1.1
Host: api.example.com
Accept: text/event-stream
Authorization: Bearer token123

سرور 200 OK کے ساتھ جواب دیتا ہے، کنکشن کو کھلا رکھتا ہے، اور وقتاً فوقتاً واقعات بھیجتا ہے۔

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache

data: {"type": "balance_update", "balance": 500000}

data: {"type": "transaction", "id": "txn_001", "amount": -5000}

event: notification
data: {"message": "Your transfer has been confirmed"}

id: 42
data: {"type": "order_status", "status": "shipped"}

ہر واقعہ کو خالی لائن سے الگ کیا جاتا ہے۔ واقعات میں شامل ہوسکتا ہے: data فیلڈ، اختیاری event اقسام اور اختیارات id دوبارہ شروع کرنے کے لیے۔

خودکار دوبارہ کنکشن

SSE کی سب سے زیادہ عملی خصوصیات میں سے ایک خودکار دوبارہ کنکشن ہے۔ اگر کنکشن کھو جاتا ہے، تو براؤزر خود بخود دوبارہ جڑ جاتا ہے اور موصول ہونے والی آخری ایونٹ ID کو بازیافت کرتا ہے۔ Last-Event-ID ہیڈر آپ اس وقت سے سرور کو دوبارہ شروع کر سکتے ہیں تاکہ یہ یقینی بنایا جا سکے کہ آپ کسی بھی ایونٹ سے محروم نہ ہوں۔

جہاں SSE جیتتا ہے۔

سادگی: SSE سادہ HTTP پر کام کرتا ہے۔ کوئی پروٹوکول اپ گریڈ کی ضرورت نہیں ہے اور کسی خاص انفراسٹرکچر کی ضرورت نہیں ہے۔ کسی بھی HTTP/2 کنکشن، لوڈ بیلنسر، اور CDN پر کام کرتا ہے جو اسٹریمنگ کو سپورٹ کرتا ہے۔

مقامی براؤزر سپورٹ: کہ EventSource API تمام جدید براؤزرز میں بنایا گیا ہے۔ بلٹ ان خودکار دوبارہ کنکشن کی خصوصیت۔

ایک طرفہ فیڈ کے لیے موزوں: لائیو ڈیش بورڈز، نوٹیفکیشن اسٹریمز، نیوز فیڈز، ریئل ٹائم اینالیٹکس، سرور لاگز: وہ تمام منظرنامے جہاں سرور مسلسل اپ ڈیٹس کے سلسلے کو آگے بڑھاتا ہے اور کلائنٹ صرف پڑھتا ہے۔

HTTP/2 ملٹی پلیکسنگ: HTTP/2 متعدد SSE کنکشنز کو ایک TCP کنکشن کا اشتراک کرنے کی اجازت دیتا ہے۔ براؤزر کنکشن کی حدود جو HTTP/1.1 پر SSE کو متاثر کرتی ہیں لاگو نہیں ہوتی ہیں۔

آپ کے موجودہ انفراسٹرکچر میں قدرتی فٹ: SSE جوابات صرف HTTP کے جوابات ہیں۔ موجودہ لوڈ بیلنسرز، تصدیقی مڈل ویئر، اور مانیٹرنگ ٹولز بغیر کسی ترمیم کے کام کریں گے۔

جہاں SSE جدوجہد کرتا ہے۔

صرف ایک سمت میں: کلائنٹ SSE کنکشن پر ڈیٹا واپس نہیں بھیج سکتا۔ دو جہتی منظرناموں کے لیے، اکیلا SSE کافی نہیں ہے۔

صرف متن (بطور ڈیفالٹ): SSE واقعات متن ہیں۔ بائنری ڈیٹا بیس 64 انکوڈ ہونا چاہیے، جو اوور ہیڈ کو جوڑتا ہے۔

تمام ماحول میں مقامی حمایت نہیں ہے۔ SSE ایک براؤزر API ہے۔ دوسرے ماحول (موبائل ایپس، سرور سے سرور) کو سٹریمنگ کے جوابات کو سنبھالنے کے لیے ترتیب شدہ HTTP کلائنٹ کی ضرورت ہوتی ہے۔

ایس ایس ای بمقابلہ ویب ساکٹ: فیصلہ

SSE کا انتخاب کریں اگر سرور ڈیٹا کو آگے بڑھاتا ہے اور کلائنٹ صرف اطلاعات، لائیو فیڈز، ڈیش بورڈز، یا AI ماڈل سے سٹریمنگ کے جوابات پڑھتا ہے۔ SSE آسان ہے، سادہ HTTP پر چلتا ہے، اور اس میں بلٹ ان آٹو ری کنیکٹ فیچر ہے۔

WebSockets کا انتخاب کریں جب کلائنٹ اور سرور دونوں کو ایک ساتھ پیغامات بھیجنے کی ضرورت ہو، جیسے چیٹنگ، شریک ترمیم، یا گیمنگ۔ WebSockets کی اضافی پیچیدگی جائز ہے جب واقعی دو طرفہ مواصلات کی ضرورت ہو۔

پروٹوکول بفرز: ڈیٹا کے لیے ایک نئی زبان

Protocol Buffer (protobuf) ایک بائنری سیریلائزیشن فارمیٹ ہے جسے گوگل نے تیار کیا ہے۔ جب کہ JSON ڈیٹا کو انسانی پڑھنے کے قابل متن کے طور پر انکوڈ کرتا ہے، پروٹوبف ڈیٹا کو کمپریسڈ بائنری کے طور پر انکوڈ کرتا ہے۔ اس واحد فرق کے پے لوڈ سائز، پارس کرنے کی رفتار، قسم کی حفاظت، اور اسکیما کے نفاذ پر جھڑپ کے اثرات ہوتے ہیں۔

سکیما-پہلا نقطہ نظر

JSON کے برعکس، جہاں آپ کلیدی قدر کے جوڑے لکھنا شروع کرتے ہیں، پروٹوبف آپ سے پہلے اسکیما کی وضاحت کرنے کا تقاضا کرتا ہے۔ ڈیٹا کا ڈھانچہ اس طرح بیان کیا گیا ہے: .proto یہ ایک فائل ہے جو پروٹوکول بفر لینگویج کا استعمال کرتی ہے، ایک زبان سے آزاد اسکیما ڈیفینیشن لینگوئج۔

اسکیما کی تعریف:

syntax = "proto3";

message User {
  string id = 1;
  string name = 2;
  string email = 3;
  double balance = 4;
  bool is_verified = 5;
  int32 kyc_level = 6;
}

message Order {
  string id = 1;
  string user_id = 2;
  double total = 3;
  string status = 4;
  int64 created_at = 5;
}

کسی بھی سٹرکچرڈ ڈیٹا فارمیٹ کی طرح، ہر فیلڈ کا ایک نام اور قسم ہوتا ہے۔ لیکن فیلڈ نمبرز بھی ہیں۔ یعنی مساوی نشان کے بعد یہ چھوٹا عدد ہے۔ یہ فیلڈ نمبر پروٹوبف کی کارکردگی کی کلید ہے۔

بائنری انکوڈنگ: فیلڈ نمبرز کیوں اہم ہیں۔

اگر پروٹوبف ڈیٹا کو بائنری کے طور پر انکوڈ کرتا ہے، تو فیلڈ کے نام آؤٹ پٹ میں ظاہر نہیں ہوں گے۔ اس کے بجائے، صرف فیلڈ نمبر اور انکوڈ شدہ قدر ریکارڈ کی جاتی ہے۔ فیلڈ 1 (id) ایک ٹیگ بائٹ ہو گا جو "فیلڈ 1، ٹائپ سٹرنگ” کی نشاندہی کرے گا اور اس کے بعد سٹرنگ کی لمبائی اور بائٹس۔ فیلڈ 4 (بیلنس) ٹیگ بائٹ ہو گا جو "فیلڈ 4، ٹائپ 64-بٹ فلوٹ” کی نشاندہی کرے گا جس کے بعد IEEE 754 ڈبل پریسیئن فلوٹنگ پوائنٹ کے 8 بائٹس ہوں گے۔

نہیں "id": تار، "balance": تار، اقتباسات، کالون، یا منحنی خطوط وحدانی۔ آپ کو بس کمپیکٹ بائنری اسٹریم کے فیلڈ ٹیگز اور اقدار کی ضرورت ہے۔

وہی صارف آبجیکٹ جو JSON میں تقریباً 100 بائٹس لیتا ہے پروٹوبف میں تقریباً 35 بائٹس لیتا ہے۔ 1000 فیلڈ انٹرپرائز API جوابات کے لیے جنہیں روزانہ لاکھوں بار کہا جاتا ہے، یہ فرق براہ راست کم بینڈوڈتھ کی کھپت اور بنیادی ڈھانچے کے اخراجات میں ترجمہ کرتا ہے۔

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

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

کوڈ جنریشن: معاہدے زندگی میں آتے ہیں۔

کہ .proto اسکیما فائل ہے۔ protoc مرتب کرنے والا یہ کمپائلر ایک ہی اسکیما تعریف سے تمام معاون زبانوں میں ڈیٹا کلاسز تیار کرتا ہے۔

ایک ہی user.proto فائل بنائی جائے گی:

• کوئی راستہ نہیں User بیک اینڈ سرورز کے لیے گو میں کلاسز

• کوئی راستہ نہیں User فلٹر کلائنٹس کے لیے ڈارٹ کلاسز

• کوئی راستہ نہیں User ڈیٹا پروسیسنگ خدمات کے لیے ازگر کی کلاسز

• کوئی راستہ نہیں User ویب فرنٹ اینڈز کے لیے ٹائپ اسکرپٹ میں کلاسز

تمام تیار کردہ کلاسوں میں ان پٹ فیلڈز، سیریلائزیشن/ڈی سیریلائزیشن کے طریقے، اور مساوات کے موازنہ ہوتے ہیں۔ کوئی دستی JSON پارسنگ، ٹائپ کاسٹنگ، یا فیلڈ کے نام کی ٹائپوز کا خطرہ نہیں۔ کمپائلر کسی بھی زبان کا اظہار ہوتا ہے۔ User ایک ہی

جب اسکیما تبدیل ہوتی ہے، مثال کے طور پر ایک نیا فیلڈ شامل کیا جاتا ہے یا فیلڈ کو ہٹا دیا جاتا ہے، تمام ٹیمیں اپنی کلاسز کو دوبارہ تخلیق کرتی ہیں۔ اگر کوئی تبدیلی ٹوٹ رہی ہے (ایک مطلوبہ فیلڈ کو ہٹا دیا گیا ہے یا کسی قسم کو غیر مطابقت پذیر طریقے سے تبدیل کیا گیا ہے)، مرتب کرنے والا تمام متاثرہ کوڈ بیسز میں غلطی کی اطلاع دیتا ہے۔ کوڈ پروڈکشن تک پہنچنے سے پہلے ہی مسائل پکڑے جاتے ہیں۔

اسکیما ارتقاء کے اصول

پروٹوبف کا فیلڈ نمبرنگ سسٹم پسماندہ مطابقت پذیر اسکیما ارتقاء کو قابل بناتا ہے۔ درج ذیل تبدیلیاں محفوظ ہیں کیونکہ فیلڈز کی شناخت ناموں کے بجائے نمبروں سے ہوتی ہے۔

• نئے نمبر کے ساتھ نیا فیلڈ شامل کرنا ہمیشہ محفوظ ہے۔ موجودہ کلائنٹس ان فیلڈز کو نظر انداز کر دیں گے جنہیں وہ نہیں پہچانتے ہیں۔ نئے کلائنٹس کو نئے شعبے ملتے ہیں۔

• کسی فیلڈ کو بطور محفوظ نشان لگا کر ہٹانا محفوظ ہے۔ حذف شدہ فیلڈز پر مشتمل موجودہ انکوڈ شدہ ڈیٹا کو ڈی کوڈ کرتے وقت نظر انداز کر دیا جاتا ہے۔ دوبارہ استعمال کو روکنے کے لیے فیلڈ نمبرز کو بطور مخصوص نشان زد کیا جانا چاہیے۔

• فیلڈز کا نام تبدیل کرنا محفوظ ہے۔ ناموں کو انکوڈ نہیں کیا گیا ہے۔ بائنری سطح پر، صرف نمبروں کی اہمیت ہے۔

• غیر موافق طریقے سے فیلڈ کی اقسام کو تبدیل کرنا غیر محفوظ ہے اور موجودہ انکوڈ شدہ ڈیٹا کو توڑ دے گا۔

اس ارتقائی ماڈل کا مطلب یہ ہے کہ پروٹوبف اسکیما تمام کلائنٹس اور سرورز میں مربوط اپ ڈیٹس کے بغیر وقت کے ساتھ بڑھ سکتا ہے۔

سمجھوتہ کی منصوبہ بندی

پروٹوبف کی کارکردگی اخراجات کے ساتھ آتی ہے جو اسے تمام حالات کے لیے غیر موزوں بناتی ہے۔

بائنری ڈیٹا انسانی پڑھنے کے قابل نہیں ہے۔ میں اس کے مواد کو دیکھنے کے لیے اپنے براؤزر کے ڈویلپر ٹولز میں پروٹوبف جواب نہیں کھول سکتا۔ ڈیبگنگ کے لیے اسکیما کا استعمال کرتے ہوئے یا خصوصی ٹولز کا استعمال کرتے ہوئے بائنری کو ڈی کوڈ کرنے کی ضرورت ہوتی ہے۔

پروٹوبف کو بھی ٹولز کی ضرورت ہوتی ہے۔ پروٹوبف انکوڈ شدہ API کے کسی بھی صارف کو اسکیما اور پروٹوبف لائبریری کو ڈی کوڈ کرنے کی ضرورت ہوگی۔ نامعلوم تیسرے فریق کے ذریعہ استعمال ہونے والے عوامی APIs کے لیے، یہ ایک اہم رکاوٹ ہے۔ JSON کو کسی چیز کی ضرورت نہیں ہے۔ آپ کسی بھی پروگرامنگ ماحول میں بلٹ ان لائبریریوں کا استعمال کرتے ہوئے JSON کو پارس کر سکتے ہیں۔

سکیما تبدیلیوں کے لیے ہم آہنگی کی ضرورت ہوتی ہے۔ جب اسکیما تبدیل ہوتا ہے، تمام صارفین کو اپ ڈیٹ کرنا ضروری ہے۔ ایک اندرونی نظام کے لیے جو تمام صارفین کو کنٹرول کرتا ہے، یہ قابل انتظام ہے۔ عوامی APIs کے لیے، آپ کو ورژن بنانے اور منتقلی کی حکمت عملی کی ضرورت ہے۔

gRPC: بڑی ریموٹ پروسیجر کالز

gRPC پروٹوکول بفرز کو HTTP/2 اور ریموٹ پروسیجر کال سیمنٹکس کے ساتھ ملاتا ہے تاکہ انٹر سروس کمیونیکیشن کے لیے ایک ایسا فریم ورک بنایا جا سکے جو استعمال کے مخصوص معاملات کے لیے REST سے زیادہ تیز، زیادہ منظم اور زیادہ مضبوط ہو۔

ریموٹ پروسیجر کالز: کلیدی تصورات

ریموٹ پروسیجر کال (RPC) فریم ورک ریموٹ سرور پر کسی فنکشن کو کال کرنے کو مقامی فنکشن کو کال کرنے جیسا محسوس کرتا ہے۔ HTTP درخواست بنانے، باڈی کو سیریلائز کرنے، جواب کو پارس کرنے اور اسٹیٹس کوڈز پر کارروائی کرنے کے بجائے، آپ ٹائپ شدہ دلائل کے ساتھ ایک فنکشن کو کال کرتے ہیں اور ٹائپ شدہ واپسی کی قیمت وصول کرتے ہیں۔ نیٹ ورک مواصلات خلاصہ ہیں۔

// Without RPC (manual REST)
const response = await http.post('/users', headers: {...}, body: json.encode(data));
const user = User.fromJson(json.decode(response.body));

// With RPC (gRPC)
final user = await userService.createUser(CreateUserRequest(name: "John", email: "john@example.com"));

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

چار مواصلاتی پیٹرن

REST پر gRPC کا سب سے اہم فائدہ یہ ہے کہ یہ مواصلات کے چار الگ الگ نمونوں کو سپورٹ کرتا ہے، سبھی یکساں طور پر بیان کیے گئے ہیں۔ .proto یہ ایک اسکیما ہے اور اسی کلائنٹ کے ذریعے اس تک رسائی حاصل کی جاسکتی ہے جس کے لیے اسے بنایا گیا تھا۔

یونری آر پی سی یہ ایک مانوس درخواست کے جواب کا نمونہ ہے۔ ایک درخواست اور ایک جواب۔ یہ ایک REST API کال کے برابر ہے۔

Client ——— LoginRequest ——→ Server
Client ←—— LoginResponse —— Server

سرور اسٹریمنگ آر پی سی ایک درخواست بھیجیں اور جوابات کا مسلسل سلسلہ حاصل کریں۔ سرور کلائنٹ کو ہر پیغام کی درخواست کیے بغیر دستیاب پیغامات کو آگے بڑھاتا ہے۔

Client ——— WatchBalanceRequest ——→ Server
Client ←— BalanceResponse ———————— Server (balance: 500,000)
Client ←— BalanceResponse ———————— Server (balance: 495,000)
Client ←— BalanceResponse ———————— Server (balance: 1,000,000)
[Stream stays open, server pushes on every change]

کلائنٹ سٹریمنگ RPC سرور کو پیغامات کا سلسلہ بھیجیں اور آخر میں ایک جواب موصول کریں۔ سرور موصول ہونے والے تمام پیغامات پر کارروائی کرتا ہے اور صرف ایک بار جواب دیتا ہے۔

Client ——— DocumentChunk 1 ——→ Server
Client ——— DocumentChunk 2 ——→ Server
Client ——— DocumentChunk 3 ——→ Server
Client ←————— UploadResponse —— Server (all chunks processed)

دو طرفہ سلسلہ بندی RPC کلائنٹ اور سرور بیک وقت اور کسی بھی ترتیب میں پیغامات کے سلسلے بھیج سکتے ہیں۔

Client ——— ChatMessage ——→ Server
Server ←— ChatMessage ——— Client
Client ——— ChatMessage ——→ Server
Server ←— ChatMessage ——— Client  (server-initiated)
[Both sides communicate freely and simultaneously]

کیوں HTTP/2 اور پروٹوبف جی آر پی سی کو موثر بناتے ہیں۔

gRPC کی کارکردگی ایک ساتھ کام کرنے والی دو بنیادی ٹیکنالوجیز کے امتزاج سے آتی ہے۔

HTTP/2 کے ملٹی پلیکس پرسنٹ کنکشن کا مطلب یہ ہے کہ بہت سی ہم آہنگی والی جی آر پی سی کالز، بشمول طویل عرصے سے چلنے والی اسٹریمنگ کالز، ایک ہی کنکشن کا اشتراک کرتی ہیں۔ فی کال کوئی کنکشن سیٹ اپ اوور ہیڈ نہیں ہے۔ متعدد سلسلے ایک دوسرے کو مسدود کیے بغیر متوازی چلتے ہیں۔

پروٹوکول بفرز کی بائنری انکوڈنگ کا مطلب ہے کہ پے لوڈ کمپیکٹ ہے اور پارس کرنا تیز ہے۔ JSON کے 100 بائٹس بھیجنے والی ایک اعلی تعدد انٹر سروس کال 35 بائٹس پروٹوبف بھیجے گی۔ مائیکرو سروسز کے درمیان فی سیکنڈ ہزاروں کالز پر، یہ فرق نمایاں ہیں۔

تیار کردہ کلائنٹ تمام سیریلائزیشن اور ڈی سیریلائزیشن کوڈ کو ہٹا دیتا ہے۔ اسکیما کلائنٹ اور سرور کو ایک معاہدے پر متفق ہونے پر مجبور کرتی ہے۔ بریکنگ تبدیلیاں مرتب کرنے والے کے ذریعہ پکڑی جاتی ہیں۔

تنظیم کے معاہدے

پیمانے پر gRPC استعمال کرنے والی تنظیمیں۔ .proto فائلیں انفرادی خدمات سے الگ وقف شدہ اسٹوریج میں واقع ہیں۔ یہ ذخیرہ تمام خدمات کے معاہدوں کے لیے آپ کی سچائی کا واحد ذریعہ ہے۔

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

یہ گورننس ماڈل API ارتقاء کو کوآرڈینیشن کے مسئلے سے کوڈ کے جائزے کے عمل میں تبدیل کرتا ہے۔

جی آر پی سی کی حدود

gRPC ویب براؤزرز میں مقامی طور پر کام نہیں کرتا ہے۔ براؤزر جی آر پی سی کو درکار کنٹرولز کے ساتھ براہ راست HTTP/2 درخواستیں نہیں کر سکتے ہیں۔ gRPC-Web کے براؤزر کے موافق فارمیٹ اور معیاری gRPC کے درمیان تبدیل کرنے کے لیے ایک پراکسی پرت (gRPC-Web) کی ضرورت ہے۔ یہ بنیادی ڈھانچے کو پیچیدہ بناتا ہے اور براؤزر پر مبنی کلائنٹس پر جی آر پی سی کے اطلاق کو محدود کرتا ہے۔

gRPC کو HTTP/2 کی بھی ضرورت ہے۔ gRPC ایسے ماحول میں استعمال نہیں کیا جا سکتا جو HTTP/2 کو سپورٹ نہیں کرتے۔

بائنری انکوڈنگ بھی ڈیبگنگ کو مزید مشکل بناتی ہے۔ gRPC ٹریفک کا معائنہ کرنے کے لیے خصوصی ٹولز اور پروٹو اسکیما تک رسائی کی ضرورت ہوتی ہے۔

فریق ثالث کے ڈویلپرز کے ذریعے استعمال کیے جانے والے عوامی APIs کے لیے، gRPC کی ٹولنگ کی ضروریات REST کے JSON سے زیادہ رکاوٹ ہیں، جو HTTP پر عالمی طور پر قابل رسائی ہے۔

مکمل موازنہ

	HTTP/1.1	HTTP/2	باقی	گراف کیو ایل	ویب ساکٹ	ایس ایس ای	جی آر پی سی
کوڈ	HTTP/1.1	HTTP/2	HTTP/1.1 یا 2	HTTP/1.1 یا 2	ویب ساکٹ	HTTP	HTTP/2
ڈیٹا فارمیٹ	کوئی بھی	کوئی بھی	JSON (عام)	JSON	کوئی بھی	متن	پروٹوبوف (بائنری)
مواصلات	درخواست کا جواب	درخواست کا جواب	درخواست کا جواب	درخواست-جواب + سبسکرپشن	دو راستہ	سرور سے کلائنٹ تک	کل 4 پیٹرن
معاہدہ	موجود نہیں ہے	موجود نہیں ہے	دستاویزات	سکیما (SDL)	موجود نہیں ہے	موجود نہیں ہے	پروٹو فائل
کوڈ جنریشن	نہیں	نہیں	اختیاری	اختیاری	نہیں	نہیں	ضروری
حقیقی وقت	نہیں	محدود (دھکا)	نہیں (پولنگ)	سبسکرائب کریں	ہاں	ہاں (ایک طرفہ)	ہاں (بلٹ ان)
براؤزر مقامی	ہاں	ہاں	ہاں	ہاں	ہاں	ہاں	نہیں (پراکسی کی ضرورت ہے)
کیشنگ	بہترین	بہترین	بہترین	مشکل	قابل اطلاق نہیں۔	قابل اطلاق نہیں۔	قابل اطلاق نہیں۔
پے لوڈ سائز	درمیانی	درمیانی	میڈیم (JSON)	میڈیم (JSON)	کم اوور ہیڈ	کم اوور ہیڈ	چھوٹا (بائنری)
انسانی پڑھنے کے قابل	ہاں	نہیں (بائنری فریم)	ہاں	ہاں	انحصار کرتا ہے	ہاں	نہیں
اسکیما کا نفاذ	موجود نہیں ہے	موجود نہیں ہے	موجود نہیں ہے	مرتب وقت	موجود نہیں ہے	موجود نہیں ہے	مرتب وقت

---

منتخب کرنے کا طریقہ: انجینئرنگ فیصلہ فریم ورک

مواصلات کا کوئی واحد طریقہ نہیں ہے جو عالمی طور پر بہترین ہو۔ ہر ایک موجود ہے کیونکہ یہ ایک مخصوص مسئلہ کو متبادل سے بہتر حل کرتا ہے۔ انجینئرنگ کے فیصلوں میں تقاضوں کے مطابق ٹولز شامل ہوتے ہیں۔

REST کب استعمال کریں۔

اگر آپ کا API عوامی ہے یا تیسرے فریق کے ذریعہ استعمال کیا جاتا ہے، تو REST استعمال کریں۔ REST کی آفاقی رسائی اسے عوامی APIs کے لیے واحد معقول انتخاب بناتی ہے۔ کسی بھی زبان میں ڈویلپر معیاری HTTP ٹولز کا استعمال کرتے ہوئے REST APIs کو کال کر سکتے ہیں۔ کوئی اسکیما فائلیں، تیار کردہ کلائنٹس، یا خصوصی لائبریریاں نہیں ہیں۔

REST بھی موزوں ہے جب کیشنگ کو ترجیح دی جائے۔ REST GET جوابات کو کسی بھی پرت پر کیش کیا جا سکتا ہے: CDN، ریورس پراکسی، براؤزر وغیرہ۔ ایسے مواد کے لیے جو بار بار تبدیل نہیں ہوتے ہیں، REST مناسب کیش ہیڈر کے ساتھ لاکھوں درخواستوں کو اوریجین سرور تک پہنچائے بغیر ہینڈل کر سکتا ہے۔

یہ مضبوط ہے یہاں تک کہ جب آپریشن ایک سادہ درخواست کا جواب ہو۔ اگر آپ اسٹریمنگ کی ضروریات یا پیچیدہ ڈیٹا خدشات کے بغیر سادہ CRUD آپریشنز بنا رہے ہیں، تو REST کو لاگو کرنا، دستاویز کرنا اور ڈیبگ کرنا کسی دوسرے متبادل کے مقابلے میں آسان ہے۔

آخر میں، اگر صارف کے لیے ڈویلپر کا تجربہ اہم ہے، تو REST استعمال کریں۔ REST API آپ کے براؤزر میں فوری طور پر قابل رسائی ہے۔ وہ ٹیسٹ کر سکتے ہیں curl. ہر ڈویلپر پہلے ہی یہ سمجھتا ہے۔

گراف کیو ایل کب استعمال کریں۔

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

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

یہ فرنٹ اینڈ ٹیموں کے لیے بھی ایک اچھا انتخاب ہے جن کو تیزی سے تکرار کرنے کی ضرورت ہے۔ ترقی تیز ہوتی ہے جب فرنٹ اینڈ بیک اینڈ کو تبدیل کیے بغیر ڈیٹا کی ضروریات کو تیار کرسکتا ہے۔ کسی نئی اسکرینز، نئے ڈیٹا کے امتزاج، یا نئے اختتامی نکات کی ضرورت نہیں ہے۔

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

WebSockets کب استعمال کریں۔

جب کلائنٹ اور سرور دونوں کو کسی بھی وقت پیغامات بھیجنے کی ضرورت ہو تو WebSockets کا استعمال کریں۔ یہ واقعی دو طرفہ، ریئل ٹائم مواصلت ہے جہاں کوئی بھی فریق کسی بھی وقت پیغام بھیج سکتا ہے۔

WebSockets چیٹنگ، تعاون اور گیمنگ کے لیے بھی موزوں ہیں۔ ریئل ٹائم چیٹ ایپلی کیشنز، باہمی تعاون کے ساتھ دستاویز میں ترمیم، اور ملٹی پلیئر ریئل ٹائم گیمز معیاری WebSocket استعمال کے کیسز ہیں۔

اور WebSockets ایک ٹھوس انتخاب ہیں جب کم لیٹنسی میسجنگ اہم ہے۔ کم سے کم فریمنگ اوور ہیڈ اور مستقل کنکشن WebSockets کو بار بار پیغامات کے تبادلے کے لیے سب سے کم تاخیر کا اختیار بناتے ہیں۔

سرور سے بھیجے گئے واقعات کا استعمال کرتے وقت

جب سرور کو اپ ڈیٹس کو آگے بڑھانے کی ضرورت ہو تو SSE استعمال کریں، لیکن کلائنٹ صرف پڑھتا ہے۔ نوٹیفکیشن فیڈز، لائیو ڈیش بورڈز، سٹریمنگ AI جوابات، ریئل ٹائم اینالیٹکس، یا کوئی بھی منظر نامہ جہاں سرور کے پاس ڈیٹا کا مسلسل سلسلہ جاری ہے اور کلائنٹ صرف استعمال کرتا ہے۔

SSE اس وقت بھی اچھا کام کرتا ہے جب آپ مکمل دو طرفہ پن پر سادگی کو اہمیت دیتے ہیں۔ SSE ایک طرفہ استعمال کے معاملات کے لیے WebSocket کے مقابلے میں لاگو کرنے اور چلانے میں بہت آسان ہے۔ خودکار دوبارہ کنکشن بنایا گیا ہے۔ یہ سادہ HTTP پر کام کرتا ہے۔

gRPC کب استعمال کریں۔

gRPC استعمال کریں جب متعدد داخلی خدمات ایک ہی معاہدے کا اشتراک کریں۔ جب متعدد ٹیمیں ایک دوسرے کو کال کرنے والی خدمات بناتی ہیں، .proto کمپائلر کے ذریعہ نافذ کردہ اسکیما معاہدے کے بڑھنے کو روکتا ہے۔ ہر کوئی سچ کے ایک ہی منبع سے اپنے گاہک تیار کرتا ہے۔

gRPC اعلی تعدد انٹر سروس مواصلات کے لیے بھی موزوں ہے۔ پروٹوبف کی کمپیکٹ بائنری انکوڈنگ اور HTTP/2 کے مسلسل ملٹی پلیکس کنکشنز سے فی سیکنڈ ہزاروں کالز کا تبادلہ کرنے والی دو مائیکرو سروسز۔

یہ بہت سے اندرونی نظاموں میں استعمال ہونے والے بڑے پے لوڈز کے لیے بھی ایک ٹھوس انتخاب ہے۔ درجنوں اندرونی ایپلی کیشنز کے ذریعہ بلائے گئے سینکڑوں فیلڈز کے ساتھ انٹرنل انٹرپرائز APIs کو پروٹوبفس کے سائز میں کمی سے بہت زیادہ فائدہ ہوتا ہے۔ کم بینڈوتھ، کم پارسنگ اوور ہیڈ، اور کمپائلڈ کنٹریکٹ انفورسمنٹ۔

جب کم بینڈوتھ نیٹ ورکس اہم ہوتے ہیں تو gRPC بھی موثر ہوتا ہے۔ متغیر یا محدود نیٹ ورک کے حالات کے ساتھ مارکیٹوں میں موبائل ایپلیکیشنز کے لیے، پروٹوبف میں بائنری انکوڈنگ JSON کے مقابلے میں پے لوڈ کے سائز کو 3 سے 10 تک کم کرتی ہے۔ 15 کلو بائٹ رسپانس اور 3 کلو بائٹ ریسپانس کے درمیان فرق 2G کنکشن پر 3-سیکنڈ لوڈ اور سب سیکنڈ لوڈ کے درمیان فرق ہے۔

آخر میں، اگر سٹریمنگ ایک بنیادی ضرورت ہے اور آپ کو ایک فریم ورک کی ضرورت ہے، gRPC استعمال کریں۔ gRPC کے چار مواصلاتی نمونے (Unary، سرور سٹریمنگ، کلائنٹ سٹریمنگ، اور دو طرفہ) APIs کے ساتھ علیحدہ WebSocket انفراسٹرکچر کی ضرورت کے بغیر تمام منظرناموں کا احاطہ کرتے ہیں۔

ہائبرڈ حقیقت

زیادہ تر جدید ترین نظام مختلف طریقوں کا استعمال کرتے ہیں، اور ہر نقطہ نظر واقعی جیتتا ہے۔

A Large Engineering Organization

Public REST API
  External developers, partners, open integrations
  JSON over HTTPS. OpenAPI documentation.
  CDN caching for frequently accessed resources.

Internal gRPC Network
  Service-to-service communication
  Auth service, payment service, notification service,
  fraud detection: all communicating with typed contracts
  over efficient binary protobuf on HTTP/2.

Real-Time Layer
  WebSockets for bidirectional features (live chat, collaboration)
  SSE for one-directional feeds (notifications, live dashboards)
  gRPC streaming for real-time data with typed contracts

Mobile API
  REST for standard operations (profile, settings, history)
  gRPC for high-frequency or large payload calls
  SSE for notification streaming

تعمیراتی پاکیزگی کی کوئی ضروریات نہیں ہیں۔ ہر پرت اپنی ضروریات کے مطابق استعمال کرتی ہے۔ نظم و ضبط یہ انتخاب جان بوجھ کر کرنے کے بارے میں ہے، نہ کہ عادت سے باہر یا پہلے سے طے شدہ۔

نتیجہ

کلائنٹس اور سرورز کیسے بات چیت کرتے ہیں اس کی تاریخ انجینئرز کی موجودہ ٹولز کی حدود کو دریافت کرنے اور بہتر ٹولز بنانے کی تاریخ ہے۔

HTTP/1.1 نے یونیورسل ریکوئسٹ رسپانس پروٹوکول فراہم کیا جس پر ویب بنایا گیا تھا۔ 1990 اور 2000 کی دہائی میں ٹیکسٹ پر مبنی فارمیٹس اور ترتیب وار لنکنگ ماڈلز نے ویب پر اچھا کام کیا۔ جیسے جیسے ایپلی کیشنز زیادہ پیچیدہ ہوتی ہیں اور کارکردگی کی توقعات بڑھ جاتی ہیں، درخواست کی حدود رکاوٹ بن جاتی ہیں۔

HTTP/2 نے نقل و حمل کی تہہ کو بائنری فریمنگ اور ملٹی پلیکسنگ کے ساتھ دوبارہ بنایا، HTTP سطح پر HOL بلاکنگ کو ختم کیا، ہیڈر کو کمپریس کیا، اور سرور پش کو فعال کیا۔ HTTP/3 TCP کو QUIC سے تبدیل کرکے، ٹرانسپورٹ کی سطح پر HOL بلاک کرنے کے باقی مسائل کو حل کرکے اور کنکشن سیٹ اپ کو تیز تر بنا کر اسے مزید آگے لے جاتا ہے۔

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

REST HTTP کی تعمیراتی طاقتوں کو اس انداز میں کوڈفائی کرتا ہے جو APIs کو عالمی طور پر قابل رسائی اور HTTP پر مبنی بناتا ہے۔ کامیابی خالصتاً تکنیکی نہیں تھی۔ یہ اس سے مماثل ہے جو ڈویلپرز پہلے ہی سمجھ چکے ہیں اور HTTP ماحولیاتی نظام نے پہلے سے کیا تعاون کیا ہے۔ ڈیٹا کی بازیافت کی کارکردگی اور ریئل ٹائم کمیونیکیشن کی حدود نے گراف کیو ایل اور اسٹریمنگ کے متبادل کے دروازے کھول دیے ہیں۔

GraphQL کنٹرول کو الٹ کر REST کے اوور فیچنگ اور کم فیچنگ کے مسائل کو حل کرتا ہے۔ کلائنٹ بالکل وہی بتاتا ہے جس کی ضرورت ہے۔ WebSockets نے REST کی صحیح معنوں میں دو طرفہ، ریئل ٹائم کمیونیکیشن کو سپورٹ کرنے میں ناکامی کو حل کیا۔ سرور کی طرف سے بھیجے گئے ایونٹس نے ایک طرفہ سلسلہ بندی کے لیے ایک آسان ریئل ٹائم آپشن فراہم کیا۔ gRPC پروٹوکول بفرز، HTTP/2، اور RPC سیمنٹکس کو ایک ایسے فریم ورک میں جوڑتا ہے جو رسمی خدمات کے درمیان بڑے پیمانے پر مواصلت پر سبقت لے جاتا ہے۔

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

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

فٹ کی یہ وضاحت وہی ہے جو انجینئرنگ کا فیصلہ عمل میں نظر آتی ہے۔