Anda perlu menyiapkan server pemesanan agar Pusat Actions dapat melakukan callback untuk membuat dan memperbarui pemesanan atas nama Anda.
- Penerapan Standar. Hal ini memungkinkan Pusat Tindakan membuat janji temu, pemesanan, dan reservasi dengan bisnis Anda atas nama pengguna.
Lihat dokumentasi Partner Portal untuk mempelajari cara mengonfigurasi koneksi ke server pemesanan sandbox dan produksi.
Menerapkan antarmuka REST API
Menerapkan antarmuka API berdasarkan REST. Hal ini memungkinkan Google mengirimkan permintaan server pemesanan melalui HTTP.
Untuk memulai, siapkan server pemesanan pengembangan atau sandbox yang dapat dihubungkan ke lingkungan sandbox Actions Center. Beralihlah ke lingkungan produksi hanya setelah server sandbox sepenuhnya diuji.
Metode
Untuk setiap jenis server pemesanan, Anda perlu memiliki kumpulan metode API yang berbeda-beda. Secara opsional, Anda dapat mendownload definisi layanan dalam format proto untuk memulai penerapan API. Tabel berikut menunjukkan metode untuk setiap penerapan dan menyertakan link ke format proto layanan.
Penerapan standar |
---|
Definisi layanan standar Download file definisi layanan proto. |
Metode | Permintaan HTTP |
---|---|
HealthCheck | GET /v3/HealthCheck/ |
BatchAvailabilityLookup | POST /v3/BatchAvailabilityLookup/ |
CreateBooking | POST /v3/CreateBooking/ |
UpdateBooking | POST /v3/UpdateBooking/ |
GetBookingStatus | POST /v3/GetBookingStatus/ |
ListBookings | POST /v3/ListBookings/ |
Resource API
Reservasi
Jenis resource berikut digunakan dalam penerapan standar:
Alur: membuat pemesanan
Bagian ini membahas cara membuat pemesanan untuk penerapan standar.
Saat pengguna membuat pemesanan, Google mengirimkan nama depan, nama belakang, nomor telepon, dan email pengguna. Dari sudut pandang Anda, pemesanan ini harus ditangani sebagai checkout tamu, karena Pusat Tindakan tidak dapat mencari akun pengguna di sistem Anda. Pastikan pemesanan akhir terlihat sama dengan pemesanan di penjual Anda yang berasal dari sistem pemesanan Anda.
Keamanan dan Autentikasi
Semua komunikasi ke server pemesanan Anda dilakukan melalui HTTPS, sehingga sangat penting bahwa server Anda memiliki sertifikat TLS valid yang cocok dengan nama DNS-nya. Untuk membantu menyiapkan server Anda, sebaiknya gunakan alat verifikasi SSL/TLS yang tersedia secara publik, seperti SSL Server Test dari 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. Sandi harus dirotasi setiap enam bulan.
Contoh Penerapan Skeleton
Untuk memulai, lihat contoh skeleton server pemesanan berikut yang ditulis untuk framework Node.js dan Java:
- Skeleton 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 terkait 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 disetel ke
200
OK, dan tentukan kegagalan logika bisnis dalam isi respons. Jenis error logika bisnis yang dapat Anda temukan akan berbeda-beda untuk berbagai jenis penerapan server.
- Tampilkan kode status HTTP yang disetel ke
Untuk penerapan Standar, kemungkinan error logika bisnis tercantum dalam Kegagalan Pemesanan dan error tersebut ditampilkan dalam respons HTTP. Error logika bisnis mungkin terjadi saat resource dibuat atau diperbarui. Misalnya, saat Anda menangani metode CreateBooking
atau
UpdatingBooking
. Contohnya mencakup, tetapi tidak terbatas pada, hal berikut:
SLOT_UNAVAILABLE
digunakan jika slot yang diminta tidak lagi tersedia.PAYMENT_ERROR_CARD_TYPE_REJECTED
digunakan jika jenis kartu kredit yang diberikan tidak diterima.
Idempotensi
Komunikasi melalui jaringan tidak selalu dapat diandalkan dan Google dapat mencoba lagi permintaan HTTP jika tidak ada respons yang diterima. Karena alasan ini, semua metode yang mengubah status harus bersifat idempotent:
CreateBooking
UpdateBooking
Untuk setiap pesan permintaan kecuali UpdateBooking
, token idempotency disertakan untuk mengidentifikasi permintaan secara unik. Hal ini memungkinkan Anda membedakan antara panggilan REST yang dicoba lagi, dengan maksud untuk membuat satu permintaan, dan dua permintaan terpisah.
UpdateBooking
diidentifikasi secara unik
oleh ID entri pemesanannya masing-masing, sehingga tidak ada
token idempotency yang disertakan dalam permintaannya.
Berikut adalah beberapa contoh bagaimana server pemesanan menangani idempotency:
Respons HTTP
CreateBooking
yang berhasil mencakup pemesanan yang dibuat. Dalam beberapa kasus, pembayaran diproses sebagai bagian dari alur pemesanan. JikaCreateBookingRequest
yang sama persis diterima untuk kedua kalinya (denganidempotency_token
yang sama),CreateBookingResponse
yang sama harus ditampilkan. Tidak ada pemesanan kedua yang dibuat, dan pengguna ditagih hanya sekali, jika sesuai.Perhatikan bahwa jika percobaan
CreateBooking
gagal dan permintaan yang sama dikirim ulang, dalam kasus ini backend Anda harus mencoba lagi.
Persyaratan idempotency berlaku untuk semua metode yang mengubah status.