REST مقابل SMPP من الناحية المفاهيمية
واجهة REST ترسل الرسائل عبر طلبات HTTPS قياسية — سهلة الربط من أي لغة برمجة أو منصة تقريباً، وهي نقطة انطلاق شائعة لمعظم التطبيقات. أما SMPP (بروتوكول نظير لنظير للرسائل القصيرة) فهو اتصال ثنائي طويل الأمد، يختاره عادة المرسلون بحجم إرسال كبير أو الأنظمة القريبة من قطاع الاتصالات التي تحتاج جلسة مستمرة عالية الإنتاجية بدل طلبات HTTP منفردة. راجع دليل المقارنة بين SMPP وREST لمعرفة كيفية الاختيار.
متى يُفضَّل كل خيار عادة
- REST: معظم تطبيقات الويب والجوال، حجم إرسال متوسط، فرق تريد أسرع مسار للربط
- SMPP: حجم إرسال مرتفع جداً، أنظمة مبنية أصلاً حول بروتوكولات الاتصالات، أو مزودون يتطلبون جلسة مستمرة للإنتاجية
مفهوم اسم المرسل (Sender ID)
اسم المرسل هو ما يراه المستلم كمصدر للرسالة — اسم تجاري بدل رقم طويل. يجب عادة تسجيل اسم المرسل واعتماده قبل الاستخدام؛ بالنسبة لـ Digital Connect، يتم تسجيل اسم المرسل عبر موقع إنتركي الرئيسي — راجع تسجيل اسم المرسل.
الـ Callbacks وWebhooks من الناحية المفاهيمية
بدل الاستعلام المتكرر عن الحالة، تسجّل معظم عمليات الربط رابط callback تُخطر عليه المنصة عند تغيّر حالة تسليم الرسالة، أو عند استلام رد (في حالات الاتصال ثنائي الاتجاه). هذا يتيح لتطبيقك التفاعل مع أحداث التسليم بشكل شبه فوري بدل التحقق المتكرر.
مفهوم حالات تقرير التسليم
يمر تقرير التسليم عادة بحالات مثل: تم الإرسال، تم التسليم، وفشل (مع رمز سبب). تصميم تطبيقك للتعامل مع كل حالة — لا فقط "تم الإرسال" — هو ما يجعل ميزات مثل إعادة محاولة OTP أو التحول الاحتياطي التشغيلي موثوقة فعلياً؛ راجع OTP والتحقق والرسائل النصية التشغيلية لمعرفة أين يهم ذلك أكثر.
الرسائل بترميز Unicode ومتعددة المقاطع
تُرسل اللغة العربية وغيرها من اللغات غير اللاتينية بترميز Unicode الذي يحتوي على حوالي 70 حرفاً بكل مقطع مقابل 160 حرفاً للنص اللاتيني GSM-7. الرسالة الأطول من مقطع واحد تُقسَّم لعدة أجزاء وتُحتسب تكلفتها وفقاً لذلك. خطّط لقوالب رسائلك مع مراعاة ذلك — يوضح دليل طول الرسالة والترميز وأداة حساب المقاطع هذا بشكل عملي.
قائمة تحقق للتخطيط للربط
- حجم الرسائل المتوقع وما إذا كان REST أو SMPP أنسب
- أي أنواع الرسائل تحتاج callbacks لحالة التسليم (OTP، تشغيلية) وأيها لا تحتاج (الحملات الجماعية)
- تسجيل واعتماد اسم المرسل قبل الإطلاق
- التحقق من طول القوالب بترميز Unicode بالعربي والإنجليزي
- تحديد سلوك بديل للرسائل الفاشلة أو غير المُسلَّمة
توثيق API الفعلي
للاطلاع على المسارات الفعلية والمصادقة وأمثلة أكواد عاملة بلغات cURL وPython وNode.js، راجع قسم المطورين في الصفحة الرئيسية — هذه الصفحة رفيقة تخطيطية له، وليست بديلاً عنه.
أسئلة شائعة
هل أستخدم REST أم SMPP لربط أنظمتي؟
REST يناسب معظم التطبيقات — أسهل بالربط ويعمل من أي بيئة برمجية. أما SMPP فيناسب المرسلين بحجم إرسال مرتفع جداً أو الأنظمة المبنية أصلاً حول بروتوكولات الاتصالات وتحتاج جلسة مستمرة. راجع دليل المقارنة بين SMPP وREST لمقارنة أدق.
ما هو تقرير التسليم ولماذا يهم؟
تقرير التسليم يخبر تطبيقك إن كانت رسالة معينة قد تم تسليمها فعلاً أو فشلت أو لا تزال قيد الانتظار — بخلاف مجرد تأكيد قبولها للإرسال. هذا مهم بشكل خاص لرسائل OTP والرسائل التشغيلية حيث يكون للفشل الصامت عواقب حقيقية.
كيف أسجل اسم المرسل؟
يتم تسجيل اسم المرسل لـ Digital Connect عبر موقع إنتركي الرئيسي — راجع تسجيل اسم المرسل لمعرفة الإجراء.
أين أجد المسارات الفعلية للـ API وأمثلة الأكواد؟
المسارات الفعلية وتفاصيل المصادقة وأمثلة الأكواد بلغات cURL وPython وNode.js موجودة في قسم المطورين بالصفحة الرئيسية. هذه الصفحة تغطي مفاهيم الربط والتخطيط، وليست التوثيق المرجعي نفسه.