إنتقل إلى المحتوى الرئيسي

قائمة التحويل

ما الذي يجب أن يغيّره التطبيق، مساراً بمسار، عند نقل استدعاء من Shukah إلى Locate. كل بند هو اختلاف كاسر (breaking) وجده تدقيق التكافؤ بتاريخ 2026-10-02: استدعاءات مزدوجة بالمدخلات نفسها على dev، أو قراءة الكود حيث لم يكن الاستدعاء الحي آمناً؛ ويذكر TL;DR كل مسار أيّهما. المسارات غير المذكورة ضمن التغييرات الكاسرة هي drop-in: يتغيّر فقط الـ base URL والمسار (انظر بنود "للمراقبة" في TL;DR كل مسار: قد يبقى الـ method أو الـ token مختلفاً). البنود المشتركة بين عدة مسارات تُذكر مرة واحدة في الأعلى، مع المسارات التي تنطبق عليها.

قبل أي شيء: احتفظ بالـ tokenين. واصل تسجيل الدخول على Shukah. احصل على JWT من Locate عبر exchange-token (target_platform: locate) وخزّن الـ tokenين كليهما. أرسل الـ JWT إلى routes العميل في خدمة المصادقة، وtoken Shukah إلى order-v2 وإلى المسارات الباقية على Shukah. لا تنقل verify-otp (تسجيل الدخول) إلى Locate حتى يقبل order-v2 الـ JWT: فتسجيل الدخول في Locate يُرجع JWT فقط، وترفضه routes النقاط في order-v2 اليوم (السبب).

اضغط على مسار لفتح صفحة الـ endpoint الخاصة به، وفيها TL;DR الكامل وجداول الحقول.

ينطبق على عدة مسارات

تغييرات كاسرة يجب معالجتها

  • GET /maeda/api/verify-otp → GET /api/v1/clients/verify-otp
    • ☐ لا تنقل تسجيل الدخول بعد: يُرجع تسجيل الدخول في Locate JWT فقط، وترفضه routes النقاط في order-v2 اليوم.
  • GET /maeda/api/verify-token → GET /api/v1/clients/verify-token
    • ☐ عند هذا الـ 401 يحذف التطبيق الـ token المخزَّن (auth.service.ts:101)، لذا استبدل الـ token أولًا.
  • GET /maeda/address-book → GET /api/v1/clients/address-book
    • ☐ العناوين التي تُنشأ على Locate قيم formatted_address وstreet وcity فيها null؛ ويرسل التطبيق formatted_address كـ c_address.
  • POST /maeda/address-book → POST /api/v1/clients/address-book
    • ☐ الاستجابة هي {status,address:{...}}؛ ويبني التطبيق الإعداد المسبق من المستوى الأعلى فتصبح id وlat/lng قيمة NaN.
    • ☐ لا يوجد geocoding: تكون street وcity وarea وstate وzipcode وcountry وformatted_address قيمتها null (وتملؤها Shukah).
  • DELETE /maeda/address-book/:id → DELETE /api/v1/clients/address-book/:id
    • ☐ يرسل التطبيق +id، فيصبح المعرّف hex ذو 24 حرفًا NaN ويجيب الحذف بـ 404؛ وتقارن الـ slice أيضًا بـ +id.
  • PUT /maeda/client/:client_id → PUT /api/v1/clients/setting
    • ☐ يبدّل التطبيق push عبر PUT client/:id؛ وتتجاهل Locate push_enabled هناك، لذا استدعِ PUT /clients/setting.
  • GET /maeda/client/point-history → GET /api/v2/client/point-history
    • ☐ تقسّم Locate إلى صفحات من 20 صفًا (الحد الأقصى 100)؛ وأرسلت Shukah كل الـ 8,136؛ ولا يرسل التطبيق ترقيمًا فيتوقف عند 20.
    • ☐ لا يوجد إجمالي ولا علامة للصفحة التالية؛ كرّر الطلب مع page وlimit (الافتراضي 20 والحد الأقصى 100) حتى صفحة قصيرة.
  • POST /maeda/point-order → POST /api/v2/client/point-orders
    • ☐ لا يوجد point_order_id: يبني التطبيق pointOrderId = String(undefined) = "undefined"؛ واسم amount صار money_amount.
    • ☐ وتغيب أيضًا: client_id وto_client_id وpoint_occasion_id وoccasion وdescription وpayment_point_order_id.
    • ☐ تحتاج routes الدفع إلى correlation_id بصيغة UUID في المسار؛ احتفظ به من create وإلا أعطى الدفع 404.
    • ☐ لم تُخصم النقاط المصروفة على جانب من الجانب الآخر خلال ثوانٍ (ولم يُفحص ما بعدها): اقرأ الرصيد والسجل من الجانب الذي يُنشئ الطلبات.
    • ☐ القيمتان payment_type بـ payfort أو hyperpay (يرسل التطبيق قيمة الإعدادات) تعطيان 400؛ ولا تعمل إلا point أو checkout.
    • ☐ يجب أن يكون point_offer_id وpoint_occasion_id معرّفَي hex من 24 حرفًا من قوائم Locate؛ والأعداد الصحيحة من Shukah تعطي 400.
  • POST /maeda/order/checkout-payment-standalone → POST /api/v2/client/point-orders/:correlation_id/pay/card
    • ☐ ينتقل معرّف الطلب من point_order_id في body (سلسلة "1252") إلى المسار بصيغة correlation_id من نوع UUID.
    • ☐ يحتفظ التطبيق بـ pointOrderId فقط؛ ومن create في Locate تكون قيمته "undefined" فيعطي الاستدعاء 404 "point order not found".
  • POST /maeda/order/checkout-payment-flow → POST /api/v2/client/point-orders/:correlation_id/pay/session
    • ☐ ينتقل معرّف الطلب من point_order_id في body (سلسلة "1253") إلى المسار بصيغة correlation_id من نوع UUID.
    • ☐ يحتفظ التطبيق بـ pointOrderId فقط؛ ومن create في Locate تكون قيمته "undefined" فيعطي الاستدعاء 404.

لم يُستبدل: واصل استدعاء Shukah

  • GET /maeda/client/status — لا يوجد route في Locate. تُعلن لقطة التطبيق هذا الـ route لكن لا يستدعيه أي كود، ومع ذلك يُظهر جدول حركة production بتاريخ 2026-10-02 عدد 768 استدعاءً خلال 3 أيام؛ وتجيب Shukah dev بـ 404 "The route maeda/client/status could not be found."
  • GET /maeda/client/delete — لا يوجد route في Locate يحذف حسابًا، لذا يواصل التطبيق استدعاء route Shukah هذا، الذي يحتاج إلى token تقبله Shukah. ويحذف التطبيق الـ token المخزَّن عند 401 هنا، لذا يُسجَّل خروج تطبيق يملك JWT فقط.
  • GET /maeda/point-order — لا يوجد route في Locate يسرد الهدايا المرسَلة لمستخدم، لذا يواصل تبويب Sent gifts استدعاء Shukah.
  • POST /maeda/order/checkout-payment — لطلبات النقاط، توفّر Locate route لبطاقة محفوظة وroute لجلسة فقط، لذا فالـ route الذي يدفع ببطاقة token من Checkout.com لا بديل له. 0 استدعاء في جدول حركة production بتاريخ 2026-10-02 (3 أيام).
  • POST /maeda/order/checkout-payment-stcpay — بحسب التصميم (D24)، يُفترض أن تعالج Locate STC Pay داخل route الدفع بالجلسة (pay-session) لا عبر endpoint STC Pay المنفصل في order-v2؛ ولم يثبت ذلك بعد على جهاز.
  • POST /maeda/order/payfort-token — PayFort مؤجَّل عن قصد لطلبات نقاط Locate، لذا يواصل مسار PayFort استدعاء Shukah. 0 استدعاء في جدول حركة production بتاريخ 2026-10-02 (3 أيام).
  • POST /maeda/order/payfort-stc-pay-checkout — PayFort مؤجَّل عن قصد لطلبات نقاط Locate، لذا يواصل مسار STC Pay هذا استدعاء Shukah. 0 استدعاء في جدول حركة production بتاريخ 2026-10-02 (3 أيام).

كيف تُنشأ هذه القائمة​

تُعرض القائمة من سجلّ الترحيل (registry.ts): كل اختلاف breaking، ثم كل مسار بتقييم blocked، ثم كل مسار ليس له بديل في Locate. لتغيير بند، غيّر مدخل السجلّ؛ انظر تقدّم الترحيل.