Menerapkan server pemesanan

Anda harus menyediakan server pemesanan untuk mengizinkan Reservasi dengan Google membuat callback guna membuat dan memperbarui pemesanan atas nama Anda.

• Penerapan Standar. Hal ini memungkinkan Reservasi dengan Google membuat janji temu, pemesanan, dan reservasi dengan Anda atas nama pengguna.

Baca dokumentasi Portal Partner untuk mempelajari cara mengonfigurasi koneksi ke server pemesanan produksi dan sandbox.

Menerapkan antarmuka REST API

Menerapkan antarmuka API berdasarkan REST. Ini memungkinkan Google mengirim permintaan server pemesanan melalui HTTP.

Untuk memulai, siapkan server pemesanan pengembangan atau sandbox yang dapat dihubungkan ke lingkungan sandbox Pesan dengan Google. Hanya pindah ke lingkungan produksi setelah server sandbox sepenuhnya diuji.

Metode

Untuk setiap jenis server pemesanan, Anda perlu menyediakan kumpulan metode API yang berbeda. Secara opsional, Anda dapat mendownload definisi layanan dalam format proto untuk memulai implementasi API. Tabel berikut menunjukkan metode untuk setiap implementasi 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:

• Slot: Slot inventaris.
• Pemesanan: Janji temu untuk slot inventaris.

Alur: membuat pemesanan

Bagian ini membahas cara membuat pemesanan untuk penerapan standar.

Gambar 1: Alur kerja untuk membuat pemesanan dari slot

Saat pengguna membuat pemesanan, Google mengirimkan nama depan, nama belakang, nomor telepon, dan email pengguna tersebut. Dari sudut pandang Anda, pemesanan ini harus diperlakukan sebagai checkout tanpa login, karena Reservasi dengan Google tidak dapat mencari akun pengguna di sistem Anda. Pastikan pemesanan akhir terlihat sama dengan pemesanan penjual yang berasal dari sistem pemesanan Anda. Checkout tanpa login dan email alternatif didukung secara default untuk pemesanan tidak berbayar.

Keamanan dan Autentikasi

Semua komunikasi ke server pemesanan Anda dilakukan melalui HTTPS, jadi 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 secara publik, seperti Uji Server SSL Qualys.

Semua permintaan yang akan dibuat Google pada 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.

Catatan: Anda harus menetapkan nama pengguna dan sandi untuk Sandbox dan Produksi secara terpisah menggunakan Pengalih lingkungan.

Contoh Penerapan Skeleton

Untuk memulai, lihat contoh framework server pemesanan berikut yang ditulis untuk framework Node.js dan Java:

• Framework Node.js js-maps-booking-rest-server-v3-skeleton
• Framework 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 terkait 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 temui berbeda untuk masing-masing jenis implementasi server.

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-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.

Idempotency

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 idempoten:

• CreateBooking
• UpdateBooking

Untuk setiap pesan permintaan kecuali UpdateBooking, token idempotensi disertakan untuk mengidentifikasi permintaan secara unik. Ini memungkinkan Anda membedakan antara panggilan REST yang dicoba lagi, dengan intent untuk membuat satu permintaan, dan dua permintaan terpisah. UpdateBooking diidentifikasi secara unik oleh ID entri pemesanannya, sehingga tidak ada token idempotensi 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. Jika CreateBookingRequest yang sama persis diterima untuk kedua kalinya (dengan idempotency_token yang sama), CreateBookingResponse yang sama harus ditampilkan. Tidak ada pemesanan kedua yang dibuat, dan pengguna ditagih hanya sekali, jika sesuai.

  Perlu diperhatikan bahwa jika upaya 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.