واجهة API للبريد مقابل SMTP: ما الفرق، وأيهما تستخدم؟

الخلاصة

1. طريقتان لتسليم الرسالة. تؤدي الواجهتان المهمة نفسها: يعطي تطبيقك رسالة إلى خدمة إرسال، وتسلّمها الخدمة إلى خادم بريد المستلم.
2. كيف يعمل SMTP لتطبيق. SMTP هو البروتوكول الذي تستخدمه خوادم البريد منذ عقود، وتقريباً لكل لغة برمجة وإطار عمل وبرنامج مكتبة له.
3. كيف تعمل API البريد. استدعاء API هو طلب HTTPS، عادةً بجسم JSON يحدد المرسِل والمستلمين والموضوع والمحتوى.
4. الفروق المهمة. الإعداد أسرع عبر SMTP حين يرسل البرنامج البريد أصلاً.
5. الأخطاء وإعادة المحاولة والتغذية الراجعة. أياً كانت الواجهة، فإن نجاح التسليم الأولي يعني فقط أن الخدمة قبلت الرسالة.
6. الأمان. تعامل مع كلمات مرور SMTP ومفاتيح API على أنها أسرار.

طريقتان لتسليم الرسالة

تؤدي الواجهتان المهمة نفسها: يعطي تطبيقك رسالة إلى خدمة إرسال، وتسلّمها الخدمة إلى خادم بريد المستلم. الفرق في كيفية التسليم الأولي.

مع SMTP يتحدث تطبيقك بروتوكول البريد إلى مرحّل. ومع API يرسل طلب ويب عادياً وتبني الخدمة الرسالة نيابةً عنك.

كيف يعمل SMTP لتطبيق

SMTP هو البروتوكول الذي تستخدمه خوادم البريد منذ عقود، وتقريباً لكل لغة برمجة وإطار عمل وبرنامج مكتبة له. تزوّدها بمضيف ومنفذ ونمط أمان وبيانات اعتماد، فتقدّم الرسالة.

Host: smtp.example.com
Port: 587 (STARTTLS)
Username and password: from your account

استخدم المنفذ 587 مع STARTTLS أو المنفذ 465 مع TLS الضمني، وهما منفذا التقديم المخصصان للتطبيقات التي تسجّل الدخول. ويعود رمز رد لكل مرحلة، مثل 250 للقبول، فيستطيع كودك معرفة هل قبل المرحّل الرسالة.

كيف تعمل API البريد

استدعاء API هو طلب HTTPS، عادةً بجسم JSON يحدد المرسِل والمستلمين والموضوع والمحتوى. تصادق بمفتاح API، وتخبرك الاستجابة هل قُبل الطلب وتمنحه معرّفاً يمكنك استخدامه لاحقاً.

POST /v1/messages
Authorization: Bearer <api key>
{"from":"you@example.com","to":"them@example.com","subject":"Hello"}

ولأن الطلب بيانات منظمة، تستطيع API فعل أمور يصعب فعلها عبر SMTP: إرسال رسالة واحدة إلى عدة مستلمين بقيمة مختلفة لكل منهم، وإرفاق وسوم خاصة بك للتتبع، واختيار قالب محفوظ وملء متغيراته.

الفروق المهمة

الإعداد أسرع عبر SMTP حين يرسل البرنامج البريد أصلاً. والتحكم أكبر عبر API التي تعيد أخطاء منظمة وتقبل خيارات لا مكان لها في بروتوكول البريد. ويمكن لطلب API واحد أن يحمل مستلمين كثيرين، بينما يحتاج SMTP إلى معاملة لكل رسالة أو لكل دفعة.

التسليم واحد في الحالتين: توقّع خدمة الإرسال الرسالة، وتختار عنوان IP، وتتحدث إلى خادم المستلم. ولا توصل أي من الواجهتين الرسالة إلى صندوق الوارد بمفردها. فالمصادقة والسمعة هما ما يفعل ذلك.

الأخطاء وإعادة المحاولة والتغذية الراجعة

أياً كانت الواجهة، فإن نجاح التسليم الأولي يعني فقط أن الخدمة قبلت الرسالة. أما هل وصلت إلى المستلم فيُبلَّغ عنه لاحقاً، على هيئة تسليم أو ارتداد أو شكوى. استخدم webhooks أو سجل الأحداث للحصول على هذه النتائج.

أعد المحاولة فقط لما فشل لسبب مؤقت. فانتهاء المهلة أو الرد 4xx يستحق إعادة المحاولة بعد تأخير، أما الرد 5xx أو العنوان المرفوض فسيفشل في كل مرة، وإعادة المحاولة لا تضيف سوى الحمل.

الأمان

تعامل مع كلمات مرور SMTP ومفاتيح API على أنها أسرار. احفظها في إعدادات البيئة، ولا تضعها أبداً في الشيفرة المصدرية أو تطبيق جوال، وامنح كل تطبيق مفتاحه الخاص حتى تستطيع إلغاء أحدها دون تعطيل الباقي.

فضّل المفاتيح المقتصرة على الإرسال، ودوّرها وفق جدول، واستخدم دائماً اتصالاً مشفراً. ينبغي استخدام الواجهتين عبر TLS.

كيف تختار

اختر SMTP حين توصل برنامجاً يرسل البريد أصلاً، مثل نظام إدارة محتوى أو نظام دعم أو تطبيق أقدم. واختر API للشيفرات الجديدة، حين تريد القوالب والقيم لكل مستلم والوسوم والاستجابات المنظمة.

أنت لست مقيّداً. فالواجهتان تتشاركان نطاقك وعناوين IP وقوائم الكتم، لذا يمكن للفريق أن يبدأ بـ SMTP ثم ينقل المسارات المزدحمة إلى API لاحقاً، واحداً تلو الآخر.

مزيد من القراءة والمصادر

• RFC 6409: تقديم الرسائل للبريد
• RFC 8314: النص الصريح يُعدّ متقادماً: TLS لتقديم البريد
• Google: إرشادات مرسِلي البريد

نفّذها في MigoSMTP: مقالات مركز المساعدة

• أمان مفاتيح API وتدويرها
• webhooks وأحداث التسليم
• إعدادات SMTP: المنافذ وTLS والمصادقة

أدلة وأدوات ذات صلة

• API البريد الإلكتروني: اطّلع على الواجهة وما تغطيه.
• مرحّل SMTP: وصّل البرمجيات الحالية.
• البريد المعاملاتي: ما هو وكيف ترسله بإتقان.
• شرح مرحّل SMTP: كيف يعمل المرحّل.