نمبر منتقلی کے منصوبے کی منسلک فائل ڈاؤن لوڈ کریں

اکاؤنٹ اور دستاویز تک رسائی

اپنے API اکاؤنٹ کی ملکیت والے نمبر منتقلی کے منصوبے سے پہلے سے موجود منسلک فائل ڈاؤن لوڈ کریں۔ کسی مجاز IP پتے سے HTTPS کے ذریعے فعال API اکاؤنٹ استعمال کریں۔ منصوبہ حذف شدہ نہیں ہونا چاہیے۔ دستاویز کے شناخت کنندے کی تلاش اسی منصوبے کے اندر ہوتی ہے؛ یہ پورے نظام میں دستیاب کوئی عوامی ڈاؤن لوڈ لنک نہیں ہے۔

دستاویز کی شناخت کریں

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

جواب میں ملنے والے نسبتی URL کو مکمل کرنے کے لیے صرف اپنے ترتیب دیے ہوئے قابل اعتماد API ہوسٹ کو بنیاد بنائیں۔ ڈاؤن لوڈ کے لیے اسی اکاؤنٹ کی توثیق درکار ہے؛ دستاویز کا میٹا ڈیٹا توثیق کے بغیر رسائی نہیں دیتا۔

درخواست بھیجیں اور جواب محفوظ کریں

اپنے اکاؤنٹ کے منصوبے کی قدریں PROJECT_ID اور DOCUMENT_ID میں مقرر کریں۔ منصوبے کے شناخت کنندے کو URL انکوڈ کریں۔ یہ مثال بائٹس اور جواب کے ہیڈرز الگ الگ محفوظ کرتی ہے اور منسلک فائل کے نام پر بھروسا کرنے کے بجائے مقامی آؤٹ پٹ کے لیے ایک مقررہ نام استعمال کرتی ہے۔

curl --silent --show-error --user "$API_USER:$API_PASSWORD" \
  --dump-header document-headers.txt \
  --output porting-document.bin \
  "https://api.multitel.net/v3/lnp/project/$PROJECT_ID/document/$DOCUMENT_ID"

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

بائنری جواب اور ہیڈرز

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

ایکسٹینشن ملاتے وقت بڑے اور چھوٹے حروف میں فرق نہیں کیا جاتا۔ MIME کی قسم محفوظ کردہ ایکسٹینشن سے منتخب ہوتی ہے، مواد کی جانچ سے نہیں، اور یہ دستاویز کے درست ہونے کی ضمانت بھی نہیں ہے۔

ڈاؤن لوڈ کی گئی فائل کی تصدیق کریں

1. HTTP اسٹیٹس اور جواب کے ہیڈرز دونوں کا معائنہ کریں۔ توثیق یا تلاش کی خرابیوں کی صورت میں فائل کے بجائے JSON کی صورت میں API جواب مل سکتا ہے۔ ہر غیر خالی باڈی یا محفوظ شدہ آؤٹ پٹ فائل کو PDF کا کامیاب ڈاؤن لوڈ نہ سمجھیں۔
2. اگر باڈی میں JSON کی صورت میں خرابی ہو تو status.code اور status.msg کا معائنہ کریں۔ خرابی کا آؤٹ پٹ متوقع دستاویز سے الگ رکھیں۔
3. چیک کریں کہ حاصل ہونے والی فائل خالی نہیں ہے اور متوقع قسم کی فائل کے طور پر کھلتی ہے۔ اگر اصل فائل آپ کے پاس محفوظ ہے تو نقل پر بھروسا کرنے سے پہلے اس کا چیک سم اصل فائل کے چیک سم سے ملائیں۔
4. اگر نتیجہ خالی، ناقص یا اصل سے مختلف ہو تو رک جائیں اور معاونت کی ٹیم سے محفوظ کردہ منسلک فائل چیک کرنے کو کہیں۔ بار بار ڈاؤن لوڈ کرنے سے ذخیرہ نظام کی خرابی درست نہیں ہوتی۔

پرانے ذخیرہ نظام سے مطابقت

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

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

موجودہ پورٹل پہلے یہ API روٹ استعمال کرتا ہے اور اس میں اضافی مقامی متبادل انتظام بھی موجود ہے۔ پورٹل سے کامیاب ڈاؤن لوڈ یہ ثابت نہیں کرتا کہ ہر پرانا ریکارڈ براہ راست اس API کے ذریعے ڈاؤن لوڈ کیا جا سکتا ہے۔

خرابیاں اور اثرات

اگر منصوبہ موجود نہ ہو، حذف ہو چکا ہو یا اکاؤنٹ کی ملکیت میں نہ ہو تو منصوبہ نہ ملنے کے پیغام کے ساتھ API کوڈ 404 ملتا ہے۔ اپنی ملکیت والے منصوبے میں اپ لوڈ موجود نہ ہو تو دستاویز نہ ملنے کے پیغام کے ساتھ API کوڈ 404 ملتا ہے۔ API کی خرابیوں کے باڈیز اور HTTP اسٹیٹس دونوں پڑھیں۔ جو ریکارڈ موجود ہو مگر اس میں قابل استعمال محفوظ بائٹس نہ ہوں، اس کے لیے اس ہینڈلر میں نہ ملنے کا کوئی مخصوص قابل اعتماد جواب نہیں ہے۔

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