مقال تقني
كيف تحولت تأكيدات Grubhub وDoorDash إلى طلبات DinDin دون واجهة للطلبات.
عندما لا يقدم نظام API عامة، يعتمد التكامل على واجهته المتاحة ولو كانت مصممة للبشر. في منظومة مطاعم DinDin كانت تلك الواجهة صندوق بريد.
قراءة الأعمال
تستقبل مطاعم DinDin الطلبات من مواقعها ونقاط بيعها وأسواق التوصيل، ويجب أن تصل جميعها إلى الطابعة والتقارير ومسار العمل نفسه. لم يوفّر Grubhub وDoorDash واجهة الطلبات اللازمة، لكنهما يرسلان تأكيد HTML إلى بريد المطعم.
قراءة الأعمال
يتصل المسار بصندوق البريد مع المصادقة، ويحلل تأكيد HTML ويطابق التاجر ويحوّل البيانات إلى نموذج طلب DinDin الأصلي، ليصل إلى طابعة المطبخ والتقارير نفسها. توضح أدلة Gmail API، المذكورة أدناه، نمطاً مرجعياً لتكامل البريد الموثق.
قراءة الأعمال
يجب تحمل انقطاع الاتصال أو إعادة معالجة الرسائل. يعتمد منع التكرار على رقم الطلب الأصلي في كل سوق، فلا ينشأ طلب مطبخ ثانٍ عند إعادة المعالجة. يشبه ذلك مبدأ الطلبات الآمنة للتكرار في توثيق Stripe المذكور أدناه.
قراءة الأعمال
عند غياب API، اختر أكثر واجهات النظام استقراراً ولو كانت موجهة للبشر، ثم اجعل إعادة التشغيل آمنة بمنع التكرار. بهذا الانضباط يصبح صندوق البريد واجهة تكامل موثوقة.
المصادر
الأدلة
منظومة مطاعم تربط الطلب الإلكتروني ونقاط البيع والإدارة وشاشات المطبخ والعملاء وطلبات الأسواق.
خدمة ذات صلة
التالي
لنناقش القيود الخاصة بنظامك.
