اکاؤنٹ اور منصوبے تک رسائی
فعال API اکاؤنٹ کو HTTPS کے ذریعے اجازت یافتہ IP پتے سے استعمال کریں۔ منصوبہ اسی اکاؤنٹ کی ملکیت ہونا چاہیے اور حذف شدہ نہیں ہونا چاہیے۔ پورٹنگ آرڈر کے طریقۂ کار سے حاصل کردہ منصوبے کا منفرد شناخت کنندہ استعمال کریں، نہ کہ ڈیٹابیس میں اس کا عددی شناخت کنندہ یا کوئی فون نمبر۔ درخواست بناتے وقت منصوبے کے شناخت کنندے کو URL انکوڈ کریں۔
نمبر شامل کرنے کی تیاری
یہ کارروائی نمبر پورٹ کرنے کے موجودہ منصوبے میں تبدیلی کرتی ہے۔ پہلے اپنے پورٹنگ آرڈر کے طریقۂ کار کے ذریعے نمبروں اور صارف کی اجازت کی تصدیق کریں۔ ہر نمبر کو مکمل بین الاقوامی ہندسوں کی صورت میں لکھیں، دہرائے گئے نمبر خود ہٹائیں اور منصوبے میں پہلے سے موجود نمبروں کی فہرست دیکھیں۔ اس اینڈ پوائنٹ کو من مانے نمبر آزمانے کے لیے استعمال نہ کریں۔
موجودہ پورٹل اس روٹ کو کال کرنے سے پہلے نمبروں کی درستی جانچتا اور انہیں معیاری صورت میں لاتا ہے۔ پرانا اینڈ پوائنٹ براہ راست استعمال کرنے پر یہی حفاظتی اقدامات فراہم نہیں کرتا: یہ اِن پٹ کے شروع اور آخر کی خالی جگہیں ہٹاتا ہے، لیکن فون نمبر کی ساخت، ملک کے کوڈ، دہرائے گئے نمبروں یا طریقۂ کار میں منصوبے کی حالت کی درستی نہیں جانچتا۔
POST درخواست
مقامی فائل numbers.json درج ذیل ساخت کے ساتھ بنائیں۔ یہ نمبر فرضی ہیں؛ ان کی جگہ منتخب منصوبے کے لیے اجازت یافتہ نمبر درج کریں۔
{
"numbers": [
"12025550123",
"12025550124"
],
"isocode": "US"
}curl --silent --show-error --user "$API_USER:$API_PASSWORD" \
--header "Content-Type: application/json" \
--data-binary @numbers.json \
"https://api.multitel.net/v3/lnp/project/$PROJECT_ID/addnumbers"| خانہ | مطلب |
|---|---|
| numbers | نمبروں کی سٹرنگز کی غیر خالی صف، یا ایسی سٹرنگ جس کی ہر نئی سطر میں ایک نمبر ہو، دینا ضروری ہے۔ خالی اندراجات نکال دیے جاتے ہیں اور شروع اور آخر کی خالی جگہیں ہٹا دی جاتی ہیں۔ کوما سے الگ کیے گئے متن کو الگ الگ نمبروں میں تقسیم نہیں کیا جاتا۔ |
| isocode | شامل کی جانے والی قطاروں کے لیے ملک کا اختیاری کوڈ۔ اسے نہ دینے یا خالی چھوڑنے پر منصوبے کا مقام استعمال ہوتا ہے۔ ہینڈلر دی گئی قدر کے شروع اور آخر کی خالی جگہیں ہٹاتا ہے، لیکن اسے بڑے حروف میں تبدیل نہیں کرتا اور نہ ہی اس کی درستی جانچتا ہے۔ ملک کا درست کوڈ بڑے حروف میں خود فراہم کریں۔ |
اس مثال کے لیے POST کو application/json کے ساتھ استعمال کریں۔ فارم کے ذریعے بھیجا گیا POST اِن پٹ بھی پڑھا جاتا ہے۔ یہ طریقہ بار بار بھیجی گئی درخواست کو ایک ہی کارروائی تک محدود رکھنے کی کلید متعین نہیں کرتا، اور نہ ہی اس اینڈ پوائنٹ کے لیے بیچ کے محفوظ حجم کی کوئی ضمانت دیتا ہے؛ اندازے کی حد پر انحصار کرنے کے بجائے قابلِ انتظام بیچوں کے ریکارڈ کا موازنہ کریں۔
رپورٹ کردہ نتیجہ
جواب کی فرضی مثال۔
{
"status": {
"code": 200,
"msg": "Success add numbers"
},
"response": {
"uniqueid": "PROJECT_EXAMPLE",
"count": 2,
"numbers": [
{
"id": 21,
"number": "12025550123",
"status": 0,
"status_str": "Pending",
"isocode": "US"
},
{
"id": 22,
"number": "12025550124",
"status": 0,
"status_str": "Pending",
"isocode": "US"
}
]
}
}جواب میں شامل کرنے کی کوشش کیے گئے اندراجات کو Pending کا نشان دیا جاتا ہے۔ یہ نتیجہ بتانے سے پہلے ڈیٹابیس میں ہر اندراج شامل ہونے کی تصدیق نہیں کرتا۔ اس لیے صرف گنتی یا واپس ملنے والا شناخت کنندہ اس بات کا ثبوت نہیں کہ ہر قطار محفوظ ہو گئی ہے۔ Pending حالت میں شامل کیا گیا اندراج نہ ٹیلی کام آپریٹر کی منظوری ہے، نہ طے شدہ منتقلی، اور نہ ہی سروس کی مکمل ہو چکی فعالی۔
دوبارہ کوشش سے پہلے ریکارڈ کا موازنہ کریں
- نمبر شامل کرنے سے پہلے منصوبے کے نمبروں کی فہرست پڑھیں اور جن نمبروں کو شامل کرنا مقصود ہے ان کی تفصیل اپنی درخواستوں کے ریکارڈ میں محفوظ رکھیں۔
- نمبر شامل کرنے کی درخواست ایک بار بھیجیں۔
- منصوبے کے نمبروں کی فہرست دوبارہ پڑھیں اور شامل کیے جانے والے ہر مطلوبہ نمبر کا موازنہ کریں۔ دہرائے گئے نمبروں اور ہر نمبر کی حالت کی جانچ کریں۔
- اگر درخواست کی مقررہ مدت ختم ہو جائے، کوئی خرابی واپس آئے یا نتیجہ مبہم ہو تو دوبارہ کوشش کرنے سے پہلے ریکارڈ دوبارہ پڑھیں۔ ممکن ہے کچھ نمبر پہلے ہی شامل ہو چکے ہوں۔
- بغیر جانچ کے پوری درخواست دوبارہ بھیجنے کے بجائے پورٹنگ آرڈر کے طریقۂ کار یا معاونت کے ذریعے غائب یا دہرائی گئی قطاروں کا مسئلہ حل کریں۔
ہینڈلر کسی ٹرانزیکشن یا تکرار سے بچاؤ کے بغیر اندراجات ایک ایک کر کے شامل کرتا ہے۔ عمل رک جانے پر پہلے سے لکھا گیا ڈیٹا برقرار رہ سکتا ہے؛ ناکام اندراج جو false واپس کرے، پھر بھی رپورٹ کردہ گنتی میں شامل ہو سکتا ہے۔ درخواست دہرانے سے دہرائی گئی قطاریں شامل ہو سکتی ہیں۔ ہینڈلر خود نہ کسی واقعے کا اندراج کرتا ہے اور نہ ہی ٹیلی کام آپریٹر کے ذریعے منتقلی مکمل کرتا ہے۔
پرانے نظام کی خرابیاں
POST کے علاوہ کوئی طریقہ استعمال کرنے پر API کوڈ 403 واپس آتا ہے۔ منصوبہ موجود نہ ہو، حذف ہو چکا ہو یا اکاؤنٹ کی ملکیت نہ ہو تو API کوڈ 404 واپس آتا ہے۔ نمبروں کا اِن پٹ خالی ہونے پر بھی API کوڈ 404 واپس آتا ہے۔ شناخت کی تصدیق اور ماخذ کے IP پتے کی پابندیاں لاگو ہوتی ہیں۔ پرانے نظام کے یہ کوڈ اس بات کا ثبوت نہیں کہ کارروائی شروع ہونے کے بعد پہلے کوئی اندراج شامل نہیں ہوا۔
بلنگ اور منتقلی کا دائرۂ کار
جس ہینڈلر کا جائزہ لیا گیا ہے وہ منصوبے کے نمبروں کی قطاریں شامل کرتا ہے اور اس میں اکاؤنٹ سے براہ راست رقم کاٹنے یا ٹیلی کام آپریٹر کو درخواست بھیجنے کا عمل شامل نہیں ہے۔ اس سے مجموعی پورٹنگ سروس مفت نہیں ہو جاتی اور نہ ہی طے شدہ پورٹنگ فیس منسوخ ہوتی ہے۔ منتقلی کی توقع کرنے سے پہلے منصوبے کی اجازت، دستاویزات اور جائزے کی ضروریات پوری کریں۔