Web Push API

Web Push API هو معيار W3C المفتوح الذي يُحدد كيفية إرسال المواقع الإلكترونية لإشعارات Push إلى المتصفحات، حتى لو كان الموقع غير مفتوح. يُحدد هذا المعيار التفاعل بين خادم التطبيق والخدمة الوسيطة للـ Push (Mozilla وGoogle FCM وApple) والمتصفح، مع تشفير شامل وفق RFC 8291.

ما هي Web Push API؟

Web Push API مواصفة W3C مفتوحة تُحدد كيفية تسليم خادم التطبيق لرسالة Push إلى متصفح. تُكمّل معيارَين مرتبطَين: Push API (RFC 8030، يصف البروتوكول بين خادم التطبيق وخدمة Push) وService Worker API (الذي يعرض الرسالة الواردة في المتصفح).

على عكس خدمات Push الخاصة كـ APNs من Apple أو FCM من Google، فإن Web Push API محايدة من ناحية المورّد: كل شركة متصفح تُشغّل نقطة خدمة Push خاصة بها تتحدث نفس البروتوكول. لذا لا تحتاج خوادم التطبيقات إلى التمييز بين Mozilla أو Google أو Microsoft — ترسل إلى عنوان URL الذي أعاده المتصفح عند الـ Opt-in.

تدفق تسليم رسالة Push

1. الاشتراك: يُسجّل الموقع service worker عند الـ Opt-in ويستدعي pushManager.subscribe(). يُنشئ المتصفح عنوان URL للنقطة النهائية ومفتاحَين تشفيريَّين (p256dh وauth) ويُعيدهما للموقع.
2. التخزين: يُرسل الموقع كائن الاشتراك إلى خادم التطبيق الذي يربطه بسجل المستخدم.
3. الإرسال: حين يريد العمل إرسال Push، يُشفّر خادم التطبيق الحمولة بالمفتاحَين وفق RFC 8291 ويُرسلها إلى عنوان URL.
4. التسليم: تُوجّه خدمة Push لمورد المتصفح الرسالة المشفرة إلى متصفح المستخدم.
5. العرض: يستقبل service worker حدث Push ويُفكّ التشفير ويستدعي showNotification() — يظهر الإشعار للمستخدم.

VAPID — تعريف المرسل

VAPID (Voluntary Application Server Identification, RFC 8292) هو الآلية التي يُعرّف بها خادم التطبيق نفسه لخدمة Push. يُوقّع الخادم كل طلب بزوج مفاتيح ECDSA (P-256). المفتاح العام يُمرَّر إلى المتصفح أثناء استدعاء الاشتراك؛ المفتاح الخاص يبقى في الخلفية. هذا يُتيح لخدمة Push التحقق من هوية المرسل ومنع الاستخدام الخاطئ.

أصبح VAPID مطلوباً من جميع المتصفحات الرئيسية منذ 2017. من يبني حلول Push مخصصة يُنشئ زوج المفاتيح مرة واحدة (مثلاً باستخدام مكتبة web-push لـ Node.js أو pywebpush لـ Python) ويستخدمه لجميع الاشتراكات.

صيغة الحمولة

Web Push API تُرسل حمولة مشفرة اعتباطية (عادةً JSON). يقرر service worker كيفية عرض الرسالة. الحقول الشائعة:

{
  "title": "تم شحن طلبك",
  "body": "طردك يصل غداً.",
  "icon": "/icon-192.png",
  "badge": "/badge-72.png",
  "url": "/orders/12345",
  "tag": "order-update"
}

الحمولة محدودة بضعة كيلوبايتات (تعتمد على المتصفح، عادةً 4 كيلوبايت). المحتوى الكبير لا يُدرج في الحمولة بل يُحمَّل عند النقر.

TTL وأفضل الممارسات

لكل رسالة Push مدة صلاحية (Time-To-Live أو TTL بالثواني) يُحددها خادم التطبيق في رأس HTTP. إذا كان المستقبل غير متصل، تحتفظ خدمة Push بالرسالة طوال TTL المحدد. للمحتوى الحساس للوقت (مثل رموز التحقق الثنائي) يُضبط TTL بين 60 و300 ثانية؛ لحملات إعادة التفاعل يمكن جعله عدة ساعات.

أفضل الممارسات: اضبط TTL على 24 ساعة افتراضياً، واستخدم رأس urgent فقط للرسائل العاجلة فعلاً. هذا يحافظ على جودة التصنيف مع خدمة Push ويمنع تأخيرات التسليم.

Web Push API في SendSeven

تستخدم SendSeven Web Push API لقناة Browser Push. مفاتيح VAPID وإدارة الاشتراكات والتشفير والتحكم في TTL كلها مُجرَّدة داخل المنصة. يُرسَل Push إما كحملة مجدولة عبر Reach لشريحة ما، أو عبر استدعاء مباشر لـ REST API من نظامك الخاص — الذي يتحكم أيضاً في التوقيت. Browser Push ليس قناة في Flow Builder؛ خطوات الرسائل القصيرة أو البريد الإلكتروني اللاحقة يمكن تنسيقها هناك.