Anda harus menyiapkan server pemesanan agar Pusat Tindakan dapat melakukan callback untuk membuat dan memperbarui pemesanan atas nama Anda.
- Penerapan Daftar Tunggu Reservasi. ID ini digunakan saat Anda berpartisipasi dalam program uji coba Daftar Tunggu Reservasi. Hal ini memungkinkan Pusat Tindakan mengambil estimasi waktu tunggu dan membuat entri daftar tunggu atas nama pengguna.
- Penerapan Standar. Hal ini memungkinkan Pusat Action membuat janji temu, pemesanan, dan reservasi dengan Anda atas nama pengguna. Untuk menerapkan server pemesanan bagi integrasi Reservasi Menyeluruh, lihat Menerapkan server pemesanan.
Lihat dokumentasi Portal Partner untuk mempelajari cara mengonfigurasi koneksi ke server pemesanan sandbox dan produksi Anda.
Menerapkan antarmuka REST API
Menerapkan antarmuka API berdasarkan REST. Hal ini memungkinkan Google mengirim permintaan server pemesanan melalui HTTP.
Untuk memulai, siapkan server pemesanan pengembangan atau sandbox yang dapat dihubungkan ke lingkungan sandbox Pusat Action. Hanya pindahkan ke lingkungan produksi setelah server sandbox sepenuhnya diuji.
Metode
Untuk setiap jenis server pemesanan, diperlukan kumpulan metode API yang berbeda. Anda juga dapat mendownload definisi layanan dalam format proto untuk memulai implementasi API. Tabel berikut menunjukkan metode untuk setiap penerapan dan menyertakan link ke format proto layanan.
Penerapan daftar tunggu |
---|
Definisi layanan daftar tunggu. Download file definisi layanan proto. |
Metode | Permintaan HTTP |
---|---|
HealthCheck | GET /v3/HealthCheck/ |
BatchGetWaitEstimates | POST /v3/BatchGetWaitEstimates/ |
CreateWaitlistEntry | POST /v3/CreateWaitlistEntry/ |
GetWaitlistEntry | POST /v3/GetWaitlistEntry/ |
DeleteWaitlistEntry | POST /v3/DeleteWaitlistEntry/ |
Resource API
Daftar tunggu
Resource berikut digunakan untuk menerapkan pemesanan berdasarkan daftar tunggu:
- WaitEstimate: Perkiraan waktu tunggu untuk penjual dan jumlah tamu tertentu.
- WaitlistEntry: Entri pengguna di daftar tunggu.
Alur: membuat entri daftar tunggu
Bagian ini membahas cara membuat pemesanan untuk integrasi Daftar Tunggu Reservasi.
![Gambar 2: Alur kerja untuk membuat entri daftar tunggu](https://developers-dot-devsite-v2-prod.appspot.com/static/actions-center/images/waitlists/rest_api_v3_waitlist_flow.png?authuser=9&hl=id)
Saat pengguna membuat entri daftar tunggu, Google mengirimkan nama depan, nama belakang, nomor telepon, dan email pengguna tersebut. Email ini sama dengan Akun Google pengguna dan diperlakukan sebagai ID unik. Dari sudut pandang Anda, daftar tunggu ini harus diperlakukan sebagai checkout tanpa login, karena Pesan dengan Google tidak dapat mencari akun pengguna di sistem Anda. Pastikan entri daftar tunggu akhir terlihat sama dengan entri di penjual Anda yang berasal dari sistem daftar tunggu Anda.
Keamanan dan Autentikasi
Semua komunikasi ke server pemesanan Anda terjadi melalui HTTPS, sehingga sangat penting bagi server Anda untuk memiliki sertifikat TLS valid yang cocok dengan nama DNS-nya. Untuk membantu menyiapkan server Anda, sebaiknya gunakan alat verifikasi SSL/TLS yang tersedia gratis, seperti SSL Server Test Qualys.
Semua permintaan yang akan dibuat Google ke server pemesanan Anda akan diautentikasi menggunakan autentikasi dasar HTTP. Kredensial autentikasi dasar (nama pengguna dan sandi) untuk server pemesanan Anda dapat dimasukkan di halaman Konfigurasi Server Pemesanan dalam Portal Partner. {i>Password<i} harus dirotasi setiap enam bulan.
Contoh Penerapan Skeleton
Untuk memulai, lihat contoh kerangka berikut dari server pemesanan yang ditulis untuk framework Node.js dan Java:
- Kerangka Node.js js-maps-booking-rest-server-v3-skeleton
- Skeleton Java java-maps-booking-rest-server-v3-skeleton
Server tersebut telah menghapus metode REST.
Persyaratan
Error HTTP dan error logika bisnis
Saat backend menangani permintaan HTTP, dua jenis error mungkin terjadi.
- Error yang terkait dengan infrastruktur atau data yang salah
- Tampilkan error ini ke klien dengan kode error HTTP standar. Lihat daftar kode status HTTP lengkap.
- Error yang terkait dengan logika bisnis
- Tampilkan kode status HTTP yang ditetapkan ke
200
OK, dan tentukan kegagalan logika bisnis dalam isi respons. Jenis error logika bisnis yang dapat Anda temui akan berbeda untuk berbagai jenis implementasi server.
- Tampilkan kode status HTTP yang ditetapkan ke
Untuk integraton Daftar Tunggu Reservasi, error logika bisnis dicatat dalam Kegagalan Logika Bisnis Daftar Tunggu dan error tersebut ditampilkan dalam respons HTTP. Error logika bisnis mungkin terjadi saat resource dibuat, misalnya saat Anda menangani metode CreateWaitlistEntry
. Contohnya termasuk, tetapi tidak terbatas pada, berikut ini:
ABOVE_MAX_PARTY_SIZE
digunakan jika entri daftar tunggu yang diminta melebihi jumlah tamu maksimum penjual.MERCHANT_CLOSED
digunakan saat daftar tunggu tidak terbuka karena penjual sudah tutup.
Idempotensi
Komunikasi melalui jaringan tidak selalu dapat diandalkan dan Google dapat mencoba lagi permintaan HTTP jika tidak ada respons yang diterima. Oleh karena itu, semua metode yang mengubah status harus idempoten:
CreateWaitlistEntry
DeleteWaitlistEntry
Untuk setiap pesan permintaan kecuali DeleteWaitlistEntry
, token idempotensi disertakan untuk mengidentifikasi permintaan secara unik. Hal ini memungkinkan Anda membedakan antara panggilan REST yang dicoba lagi, dengan intent untuk membuat satu permintaan, dan dua permintaan terpisah.
DeleteWaitlistEntry
masing-masing diidentifikasi secara unik oleh ID entri daftar tunggunya, sehingga tidak ada token idempotensi yang disertakan dalam permintaannya.
Berikut adalah beberapa contoh bagaimana server pemesanan menangani idempotency:
Respons HTTP
CreateWaitlistEntry
yang berhasil mencakup ID entri daftar tunggu yang dibuat. JikaCreateWaitlistEntryRequest
yang sama diterima untuk kedua kalinya (denganidempotency_token
yang sama),CreateWaitlistEntryResponse
yang sama harus ditampilkan. Tidak ada entri daftar tunggu kedua yang dibuat dan tidak ada error yang ditampilkan.Perhatikan bahwa jika percobaan
CreateWaitlistEntry
gagal dan permintaan yang sama dikirim ulang, dalam kasus ini backend Anda harus mencoba lagi.
Persyaratan idempotency berlaku untuk semua metode yang mengubah status.