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

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

الخلاصات

• إذا لم يتم ضبط طول الخدمة، اضبط duration_sec في خلاصة مدى التوفّر على أي مما يلي:
  • تمثّل هذه السمة عدد الثواني المستغرقة لتقديم الخدمة بطريقة معقولة.

  • متوسط عدد الثواني اللازمة لإكمال الخدمة.

• ويجب أن يكون إدخال الحقل Category في خلاصة التاجر محددًا. على سبيل المثال، قد يرسل مطعم نوعًا محدّدًا، مثل فرنسي أو ياباني. للحصول على التفاصيل، راجِع أنواع الأماكن للتعرّف على قيم الفئات المحتملة.

• اضبط بنود الخدمة الخاصة بالتاجر في الحقل Terms ضمن خلاصة التاجر لكي تظهر الملاحظة التالية أسفل الزر حجز:

  تشير المتابعة إلى موافقتك على بنود خدمة <merchant>.

  في هذه الحالة، تشكّل "بنود الخدمة" رابطًا يعرض النص الذي تم إدخاله في الحقل النصي البنود عند النقر عليه.

• ضغط الخلاصات باستخدام gzip

خادم الحجز

لتحسين تكامل API للحجز في الخرائط، قم بما يلي:

• استخدِم دائمًا الطوابع الزمنية لـ UNIX بتنسيق UTC.
• يمكنك إنشاء معرّف حجز فريد عند طلب حجز جديد في CreateBooking API.

تحديثات في الوقت الفعلي

لضمان تقديم أفضل تجربة للمستخدم أثناء عملية الحجز، يُرجى اتّباع الخطوات التالية:

• لاستخدام طريقة العرض العادية، يمكنك استخدام BookingNotifications API لتغيير وقت بدء موعد ومدته وحالة الحجز، مثل إلغاء موعد أو عدم الحضور.
• عند إجراء أي تغيير على الحجز في "مركز الإجراءات" من جانبك، يمكنك دائمًا إرسال إشعارات الحجز في الوقت الفعلي من النظام باستخدام BookingNotification API في الوقت الفعلي كي لا تصبح البيانات قديمة من جهة "مركز الإجراءات". على سبيل المثال، يمكنك إلغاء حجز أو إعادة جدولته أو تعديله من نظامك في "مركز الإجراءات".
• لكل تعديل على الحجز من UpdateBookingRequest، تأكَّد من أنّ قيمة UpdateBookingResponse تحتوي على رقم تعريف الحجز، وأنّ جميع الحقول المعدَّلة يجب أن تعكس القيمة الجديدة.
• في حال تنفيذ RTU في المستودع
  • قم بتحديث التوفر فقط على مجموعات من 100-1000 خانة لكل طلب بيانات من واجهة برمجة التطبيقات.
  • استخدِم الحقول *Restrict (مثل startTimeRestrict) لتضييق هدف التعديل وتقليل حجم الحمولة وتجنُّب إعادة إرسال الكثير من البيانات التي لم تتغيّر.
  • إذا أوقفت عدة سلاسل محادثات، يمكنك تنفيذ سياسة التراجع الأسّي لمنع أخطاء التقييد. إذا لم تنفِّذ عملية تراجع أُسيّ بشكل صحيح، قد تحصل على RESOURCE_EXHAUSTED خطأ في الحصّة. يمكنك إعادة محاولة الزحف الأُسيّ لمعالجتها، ولكن إذا وجدت أنّ خادمك غالبًا ما يصل إلى الحصص عند تشغيل ReplaceServiceAvailability، يمكنك ضبط خادمك على تقسيم عمليات الاستبدال المجمّعة لتوفُّر. يمنع هذا الحل أخطاء الحصة لأنه يقلل من عدد طلبات البيانات من واجهة برمجة التطبيقات التي يجب أن يجريها عرضك.
• ضبط حدود وقت الاستجابة لطلب البيانات من واجهة برمجة التطبيقات على أقل من ثانية واحدة تأكَّد من أنّ الخادم يمكنه معالجة خمسة طلبات في الثانية (QPS) بوقت استجابة أقل من الثانية بنسبة لا تقل عن 95% من الوقت.