Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Untuk menyelesaikan tugas pencapaian CreateBooking Siap, Anda harus berhasil
membangun dan mengirimkan metode CreateBooking. Metode ini dipanggil saat pengguna
berupaya membuat pemesanan. Jika pemesanan berhasil dibuat, respons
akan menyertakan booking_id unik untuk merujuk ke pemesanan untuk permintaan atau
pembaruan mendatang.
Persyaratan tugas CreateBooking
10 respons CreateBooking yang berhasil dengan tingkat error kurang dari 10%.
Dasar-dasar CreateBooking
Saat pengguna memulai pemesanan, permintaan CreateBooking akan dikirim ke
Server Pemesanan partner. Respons terhadap permintaan menunjukkan apakah pemesanan berhasil atau gagal. Jika terjadi kegagalan pemesanan, respons harus menyertakan error logika bisnis untuk kegagalan. Misalnya, slot menjadi tidak tersedia atau slot telah dipesan oleh pengguna yang sama.
Saat pengguna membuat pemesanan, Google mengirimkan nama depan, nama belakang, nomor telepon, dan email pengguna. Untuk mengetahui informasi selengkapnya, lihat
Kebijakan pencocokan dan pembuatan akun.
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. ID entri pemesanan UpdateBooking masing-masing membantu mengidentifikasi UpdateBooking secara unik, 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. Jika CreateBookingRequest yang sama 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.
Persyaratan idempotency berlaku untuk semua metode yang mengubah status.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-07-26 UTC."],[],[],null,["# CreateBooking Ready\n\nTo complete the `CreateBooking` Ready milestone task, you need to successfully\nbuild and deliver the `CreateBooking` method. This method is called when a user\nattempts to create a booking. If a successful booking is created, the response\nincludes a unique `booking_id` to refer to the booking for future requests or\nupdates.\n\nCreateBooking task requirements\n-------------------------------\n\n- 10 successful `CreateBooking` responses with an error rate less than 10%.\n\nCreateBooking basics\n--------------------\n\nWhen a user initiates a booking, a `CreateBooking` request is sent to the\npartner Booking Server. The response to the request indicates either a\nsuccessful booking or booking failure. If there is a booking failure, the\nresponse needs to include the business logic error for failure. For example, the\nslot has become unavailable or the slot has been already booked by the same\nuser.\n\nWhen a user creates a booking, Google sends you the user's given name, surname,\nphone number, and email. For more information, see\n[Account matching and creation policy](/actions-center/verticals/reservations/e2e/policies/platform-policies#account_matching_and_creation_policy).\n| **Note:** Business logic errors must be returned in the `CreateBookingResponse.booking_failure` field, rather than through a non-200 HTTP response code.\n| **Warning:** Booking failures because of the unavailability of the slot are considered `CreateBooking` errors. Your integration can be disabled when there are many `CreateBooking` errors. High error rate for `CreateBooking` availability errors indicate that your `BatchAvailabilityLookup` slot click response doesn't accurately reflect real-time inventory.\n\n### Idempotency\n\nCommunication over the network isn't always reliable, and Google can retry HTTP\nrequests if no response is received. For this reason, all methods that mutate\nstate must be idempotent:\n\n- `CreateBooking`\n- `UpdateBooking`\n\nFor every request message, except `UpdateBooking`, idempotency tokens are\nincluded to uniquely identify the request. This lets you distinguish between a\nretried REST call, with the intent to create a single request and two separate\nrequests. The respective booking entry IDs of the `UpdateBooking` help to\nuniquely identify them, so no idempotency token is included in their requests.\n\nThe following are some examples of how Booking Servers handle idempotency:\n\n- A successful\n [`CreateBooking`](/actions-center/verticals/reservations/e2e/reference/booking-server-api-rest/e2e-methods/createbooking-method)\n HTTP response includes the created booking. In some cases, payment is processed\n as part of the booking flow. If the same `CreateBookingRequest` is received a\n second time with the same `idempotency_token`, the same `CreateBookingResponse`\n must be returned. A second booking isn't created, and\n the user is charged exactly once, if applicable.\n\n | **Note:** If a `CreateBooking` attempt fails and the same request is re-sent, your backend must retry the `CreateBooking` request.\n\nThe idempotency requirement applies to all methods that mutate state."]]
