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

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

الخلاصات

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

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

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

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

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

  في هذه الحالة، "بنود الخدمة" هو رابط يؤدي عند النقر عليه إلى عرض النص الذي تم ضبطه في حقل النص terms.

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

خادم الحجز

لتحسين عملية دمج واجهة برمجة التطبيقات Maps Booking API، اتّبِع الخطوات التالية:

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

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

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

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