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

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

الخلاصات

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

  • يجب تحديد حقل الحقل Category في خلاصة التاجر. على سبيل المثال، قد يرسل مطعم مطعمًا من نوع معيّن، مثل الفرنسية أو اليابانية. لمعرفة التفاصيل، يُرجى الاطّلاع على أنواع الأماكن لمعرفة قيم الفئات المحتملة.
  • اضبط بنود الخدمة الخاصة بالتاجر في الحقل Terms في خلاصة التاجر بحيث تظهر الملاحظة التالية أسفل الزر حجز:

    تعني المتابعة موافقتك على بنود خدمة <merchant>.
    في هذه الحالة، تمثل "بنود الخدمة" رابطًا يعرض النص المحدّد في حقل النص terms عند النقر عليه.

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

خادم الحجز

لتحسين تكامل واجهة برمجة تطبيقات الحجز في "خرائط Google"، يمكنك تنفيذ ما يلي:

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

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

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

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