Praktik terbaik

Praktik terbaik berikut berlaku untuk integrasi Daftar Tunggu Reservasi Pusat Tindakan dan dapat dimanfaatkan untuk menghindari masalah kegunaan dan performa. Kualitas data yang rendah dapat menyebabkan penghapusan inventaris.

Feed

  • Jika layanan tidak memiliki durasi yang ditetapkan, tetapkan duration_sec di feed Ketersediaan ke salah satu opsi berikut:
    • Jumlah detik yang diperlukan untuk menjalankan layanan secara wajar.

    • Jumlah detik rata-rata yang diperlukan untuk menyelesaikan layanan.

  • Buat input kolom Category di feed penjual bersifat spesifik. Misalnya, restoran mungkin mengirimkan jenis tertentu, seperti Prancis atau Jepang. Untuk mengetahui detailnya, lihat Jenis tempat untuk nilai kategori potensial.

  • Tetapkan persyaratan layanan khusus penjual di kolom Terms pada feed Penjual sehingga catatan berikut muncul di bawah tombol Pesan:

    Dengan melanjutkan, Anda menyetujui Persyaratan Layanan <merchant>.
    Dalam hal ini, "Persyaratan Layanan" adalah link yang, jika diklik, akan menampilkan teks yang ditetapkan di kolom teks terms.

  • Kompresi feed Anda menggunakan gzip

Server Pemesanan

Untuk mengoptimalkan integrasi Maps Booking API, lakukan hal berikut:

  • Selalu gunakan stempel waktu UNIX dalam format UTC.
  • Buat ID pemesanan yang unik saat pemesanan baru di API CreateBooking dipanggil.

Update realtime

Untuk memastikan pengalaman pengguna terbaik selama proses pemesanan, lakukan langkah berikut:

  • Untuk penerapan standar, gunakan BookingNotifications API untuk mengubah waktu mulai, durasi, dan status pemesanan, seperti pembatalan atau ketidakhadiran janji temu.
  • Setelah ada perubahan pada pemesanan Pusat Action dari Anda, selalu kirim pembaruan pemesanan real-time dari sistem dengan BookingNotification API secara real-time sehingga data tidak menjadi usang di sisi Pusat Tindakan. Misalnya, Anda dapat membatalkan, menjadwalkan ulang, atau memperbarui pemesanan dari sistem di Pusat Action.
  • Untuk setiap pembaruan pemesanan dari UpdateBookingRequest, pastikan nilai UpdateBookingResponse berisi ID pemesanan dan semua kolom yang diperbarui harus mencerminkan nilai baru.
  • Jika RTU Inventaris diimplementasikan
    • Hanya perbarui ketersediaan dalam batch 100-1.000 slot per panggilan API.
    • Gunakan kolom *Restrict (seperti startTimeRestrict) untuk mempersempit target edit, mengurangi ukuran payload, dan menghindari pengiriman ulang terlalu banyak data yang tidak diubah.
    • Jika Anda melepaskan beberapa thread, implementasikan backoff eksponensial untuk mencegah error throttle. Jika tidak mengimplementasikan backoff eksponensial dengan benar, Anda mungkin akan mendapatkan error kuota RESOURCE_EXHAUSTED. Anda dapat mencoba lagi backoff eksponensial untuk menanganinya, tetapi, jika server Anda sering mencapai kuota saat menjalankan ReplaceServiceAvailability, konfigurasikan server Anda ke penggantian batch untuk ketersediaan. Solusi ini mencegah error kuota karena mengurangi jumlah panggilan API yang harus dilakukan penyaluran Anda.
  • Setel batas waktu respons panggilan API Anda ke kurang dari satu detik. Pastikan server Anda dapat menangani lima kueri per detik (QPS) dengan latensi sub-detik setidaknya 95% sepanjang waktu.