SMPP مقابل HTTP (REST) API لرسائل SMS.
توفّر BroadNet كلا الخيارين: واجهة HTTP (REST) لرسائل SMS وروابط SMPP؛ ويعتمد الخيار الأنسب على حجم الإرسال المستمر لديك وطريقة التكامل. واجهة SMS بأسلوب REST هي الأداة الصحيحة لكل فريق هندسي حديث تقريبًا — فهي ودودة لجدار الحماية، ومحايدة للغة، وسهلة التكامل. لا تضع BroadNet أي حدود معدل ثابتة لكل حساب على REST؛ أمّا SMPP فهو الأداة الصحيحة عندما ترسل باستمرار عدة مئات من الرسائل في الثانية أو تحتاج إلى اتصالات ربط دائمة، أو لأي عبء يحتاج كفاءة ثنائية ودلالات DLR كاملة. معظم عملاء BroadNet يبدؤون بـ REST ويضيفون ارتباط SMPP حين يبرّر حجمهم ذلك.
12 صفًا. دون مواربة.
المعايير نفسها في العمودين. حيثما يعتمد الصف فعلاً على حالة الاستخدام، يقول الجدول ذلك. وحيثما يكون أحد الطرفين الأداة الأفضل بوضوح، يقول الجدول ذلك أيضًا.
| القدرة | العمود أ SMS API (REST) HTTPS / JSON | العمود ب SMPP بروتوكول نظير إلى نظير للرسائل القصيرة (Short Message Peer-to-Peer) 3.4 / 5.0 |
|---|---|---|
البروتوكول | HTTPS POST + JSON | TCP ثنائي، جلسة دائمة |
المنفذ الافتراضي | 443 (TLS) | 2775 (غير مشفّر)؛ منفذ TLS مُرفق بحسابك |
المصادقة | رمز Bearer / مفتاح واجهة | system_id + كلمة مرور عند الربط (bind) |
نموذج الجلسة | طلب/استجابة عديم الحالة | جلسة ربط (bind) طويلة الأمد للإرسال والاستقبال |
سقف معدّل النقل | لا توجد حدود معدل ثابتة لكل حساب؛ يتم تحديد الحجم وفقًا لحركة الرسائل الخاصة بك | لا توجد حدود معدل ثابتة لكل حساب؛ ما يصل إلى 30,000 رسالة SMS في الثانية لكل عقدة |
عدم التكرار (Idempotency) | لا يوجد رأس idempotency: احتفظ بمعرّف الرسالة المُعاد وتحقق من الحالة قبل إعادة الإرسال | لا يوجد شيء في البروتوكول: sequence_number يربط الاستجابة بطلبها فقط |
نموذج إيصال التسليم | استدعاء ويب‑هوك | deliver_sm على الجلسة نفسها |
التحكّم في الترميز | تلقائي (GSM-7 / UCS-2) | معامل data_coding يدوي |
معالجة SMS المتسلسلة | تقسيم تلقائي | UDH يدوي أو message_payload |
معالجة MO الوارد | استدعاء ويب‑هوك | الجلسة نفسها، deliver_sm |
جهد التكامل | دقائق (curl) إلى ساعات | أسبوع إلى أسبوعين (منطق الربط، إعادة المحاولة، إبقاء الجلسة) |
الأنسب لـ | تطبيقات الويب، النماذج الأولية، الحجم المنخفض إلى المتوسّط | الحجم العالي المستدام، المجمّعون، شركات الاتصالات |
تُراجَع فصليًا · أرسل التصحيحات إلى press@broadnet.me
bind_transceiverفتح الجلسة والمصادقة عليهاbind_transceiver_respتم قبول الجلسةsubmit_smإرسال رسالةsubmit_sm_respتم القبول، وإعادة معرف الرسالةdeliver_smإيصال استلام أو رسالة واردةdeliver_sm_respتم التأكيدenquire_linkإشارة Keepalive أثناء الخمول
أي طرف يناسب أي عبء عمل.
متى تختار واجهة SMS بأسلوب REST
اختر REST عندما يكون العبء متوسّط الحجم، والفريق أصيل في الويب، وجدول التكامل قصيرًا. REST هو الخيار الحديث الافتراضي لكل عميل CPaaS تقريبًا في 2026.
- أحجام الرسائل التي لا يشكل فيها العبء الإضافي لبروتوكول HTTPS لكل طلب عنق الزجاجة.
- الفرق التي تكون بنيتها التقنية أصلًا أصيلة في HTTP (تطبيقات ويب، خوادم بلا حالة، خلفيات محمول).
- الأعباء التي تتفوّق فيها سهولة التكامل على كفاءة معدّل النقل الخام.
- تنسيق متعدّد القنوات حيث يجلس SMS إلى جانب WhatsApp وRCS والبريد.
متى تختار SMPP
اختر SMPP عندما يكون معدّل النقل المستدام أو التحكّم الكامل في DLR أو العمليات بأسلوب المجمّعين في الصورة. SMPP أقدم وأغرب من REST، لكنه البروتوكول الذي يدور عليه عالم الاتصالات فعلًا، وعند الحجم تكون الكفاءة حقيقية.
- إرسال مستدام بعدة مئات من الرسائل في الثانية، أو أعباء تحتاج إلى اتصالات ربط دائمة، حيث يبدأ REST بالشعور بكلفة تأسيس الاتصال.
- الأعباء التي تحتاج تحكّمًا كاملًا في data_coding وفترات الصلاحية وmessage_payload.
- الفرق التي تشغّل MO الوارد بحجم عالٍ وتحتاج deliver_sm على الجلسة نفسها.
- المجمّعون وشركات الاتصالات وكل من يشغّل المراسلة كوظيفة عمل أساسية.
أين تقف BroadNet.
تموضع صادق، لا عرض ترويجي. أحيانًا يكون الجواب الصحيح هو استخدام الطرف الآخر من هذه المقارنة — وسنخبرك متى.
تحدّث إلى خبير اتصالاتنقدّم كليهما، ونشجّع العملاء على البدء حيث يكون فريقهم أكثر إنتاجية. بالنسبة لمعظم الفرق الأصيلة في الويب، يعني ذلك REST. تغطّي نقطتنا POST /sms/sendSms ومواصفة OpenAPI 3.1 وحزمة SDK الرسمية للغة TypeScript تسعين بالمئة من احتياجات العملاء دون لمس SMPP إطلاقًا.
حيث يصبح SMPP هو الجواب الصحيح هو عتبة الحجم — عدة مئات من الرسائل في الثانية بشكل مستمر — حين يبدأ تفاوض HTTPS لكل طلب بالهيمنة على ميزانية الزمن ويصبح تجميع الاتصالات مشكلة تستحقّ الحلّ. عند هذه النقطة، نقدم ربط جهاز إرسال واستقبال SMPP 3.4 مشفر بتقنية TLS، دون حدود معدل ثابتة لكل حساب، وبحجم يتناسب مع حركة رسائلك حتى 30,000 رسالة SMS في الثانية لكل عقدة؛ ويتم توفير المضيف والمنفذ وبيانات الاعتماد مع وصول الاختبار الخاص بك.
ندعم أيضًا SMPP 5.0 للعملاء الذين يحتاجون دلالات message_payload الأحدث، أو معالجة البثّ، أو التقارير الأنظف للحالة. عمليًا، خمسة وتسعون بالمئة من حركة SMPP في الاتصالات عالميًا لا تزال 3.4، ونعامل 3.4 كافتراضي.
نمط شائع: REST لشيفرة طبقة التطبيق التي ترسل رموز OTP وإشعارات فردية، وSMPP لمرسِل الحملات والجملة عالي الحجم. كلاهما يرتبط بـSMSC نفسه، وكلاهما ينتج الإيصالات نفسها، وكلاهما يُفوتَر على بطاقة الأسعار نفسها. يمكن للعملاء المزج دون تفكير.
الأسئلة الأكثر تكرارًا.
ما هو SMPP بالضبط؟
+
ما هو SMPP بالضبط؟
بروتوكول Short Message Peer-to-Peer (نظير إلى نظير للرسائل القصيرة) — بروتوكول TCP ثنائي صُمّم في أواخر التسعينيات لتسليم SMS بين مراكز SMSC وكيانات الرسائل الخارجية (ESME، أي التطبيقات). وهو البروتوكول الذي تركبه فعليًا معظم حركة A2P بمستوى الاتصالات بين المجمّعين والمشغّلين.
هل SMPP أصعب في التكامل من REST؟
+
هل SMPP أصعب في التكامل من REST؟
أصعب بشكل ملحوظ. تحتاج جلسة مرتبطة طويلة الأمد، ومنطق إبقاء (enquire_link)، وإدارة أرقام التسلسل، ووعيًا بالترميز، ومعالجة حالة الربط. معظم الفرق تستخدم مكتبة SMPP قائمة — Cloudhopper لـ Java، وsmpp.js لـ Node، وjSMPP لمؤسسات Java.
لماذا لا يزال المرسلون عالو الحجم يستخدمون SMPP في 2026؟
+
لماذا لا يزال المرسلون عالو الحجم يستخدمون SMPP في 2026؟
كفاءة معدّل النقل. تستطيع جلسة SMPP مرتبطة واحدة دفع أكثر من 1,000 رسالة في الثانية لكل مرسِل‑مستقبِل، بينما يتطلّب REST تفاوض TLS جديدًا لكل طلب ما لم تجمّع الاتصالات بعناية. للحجم العالي المستدام، البروتوكول الثنائي أكفأ بشكل ملحوظ.
هل تكشف BroadNet SMPP أم REST أولًا؟
+
هل تكشف BroadNet SMPP أم REST أولًا؟
كليهما، مع REST كافتراضي للتسجيلات الجديدة وSMPP كحوار مبيعات للأعباء التي تحافظ على عدة مئات من الرسائل في الثانية أو تحتاج إلى اتصالات ربط دائمة. SMSC نفسه خلف كليهما؛ ودلالات DLR نفسها تنطبق.
ماذا عن SMPP 5.0؟
+
ماذا عن SMPP 5.0؟
ندعمه. عمليًا، لا تزال الغالبية العظمى من حركة A2P عبر SMPP عالميًا تستخدم 3.4، ونعامل 3.4 كافتراضي للارتباطات الجديدة ما لم يطلب العميل 5.0 تحديدًا.
هل أستطيع تشغيل REST وSMPP من الحساب نفسه؟
+
هل أستطيع تشغيل REST وSMPP من الحساب نفسه؟
نعم، مقابل SMSC نفسه. معظم عملاء المؤسسات يفعلون ذلك بالضبط — REST لشيفرة طبقة التطبيق وSMPP للمرسِل عالي الحجم.
كيف تُعالَج إيصالات التسليم بشكل مختلف؟
+
كيف تُعالَج إيصالات التسليم بشكل مختلف؟
يحصل REST على استدعاء ويب‑هوك على العنوان الذي سجّلته. ويحصل SMPP على إطارات deliver_sm على الجلسة نفسها التي أرسلت الرسالة. كلاهما يحمل حقول DLR نفسها وحمولة الإيصال نفسها عند طبقة BroadNet.
هل أفقد إمكانية تسليم الرسائل باختياري REST بدلاً من SMPP؟
+
هل أفقد إمكانية تسليم الرسائل باختياري REST بدلاً من SMPP؟
لا. تمر الرسالة نفسها عبر مركز خدمة الرسائل القصيرة نفسه وعبر مسار المشغّل نفسه خلف كلا الطرفين - دقة تقارير DLR والتوجيه متطابقتان. الخيار تشغيلي بحت، وليس له علاقة بمفاضلة إمكانية التسليم.
قراءات ذات صلة.
كل المقارناتمقارنات أخرى.
تحدّث إلى خبير اتصالات.
أخبرنا بعبء العمل والأسواق والأحجام. وسنخبرك بصدق ما إذا كانت BroadNet الخيار المناسب أو غير المناسب، أو جزءًا من بنية متعددة الطبقات مع أحد البدائل.