Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Để hoàn thành nhiệm vụ CreateBooking Ready (Sẵn sàng) trong cột mốc, bạn cần xây dựng và phân phối thành công phương thức CreateBooking. Phương thức này được gọi khi người dùng cố gắng tạo một lượt đặt phòng. Nếu bạn tạo thành công một lượt đặt chỗ, thì phản hồi sẽ bao gồm một booking_id duy nhất để tham chiếu đến lượt đặt chỗ cho các yêu cầu hoặc nội dung cập nhật trong tương lai.
Yêu cầu đối với việc cần làm CreateBooking
10 phản hồi CreateBooking thành công với tỷ lệ lỗi dưới 10%.
Kiến thức cơ bản về CreateBooking
Khi người dùng bắt đầu đặt chỗ, yêu cầu CreateBooking sẽ được gửi đến Máy chủ đặt chỗ của đối tác. Phản hồi cho yêu cầu cho biết việc đặt phòng thành công hoặc không thành công. Nếu có lỗi đặt phòng, thì phản hồi cần phải bao gồm lỗi logic nghiệp vụ đối với lỗi. Ví dụ: khung giờ đã hết hoặc đã được người dùng đặt trước.
Khi người dùng tạo một lượt đặt phòng, Google sẽ gửi cho bạn tên, họ, số điện thoại và email của người dùng. Để biết thêm thông tin, hãy xem Chính sách về việc tạo và so khớp tài khoản.
Tính chất luỹ đẳng
Giao tiếp qua mạng không phải lúc nào cũng đáng tin cậy và Google có thể thử lại các yêu cầu HTTP nếu không nhận được phản hồi. Vì lý do này, tất cả các phương thức làm thay đổi trạng thái đều phải có tính chất luỹ đẳng:
CreateBooking
UpdateBooking
Đối với mọi thông báo yêu cầu, ngoại trừ UpdateBooking, mã thông báo về tính chất luỹ đẳng được đưa vào để xác định duy nhất yêu cầu. Điều này cho phép bạn phân biệt giữa một lệnh gọi REST được thử lại, với mục đích tạo một yêu cầu duy nhất và hai yêu cầu riêng biệt. Mã đặt phòng tương ứng của UpdateBooking giúp xác định riêng từng mã, vì vậy, không có mã thông báo về tính chất luỹ đẳng được đưa vào yêu cầu của các mã này.
Sau đây là một số ví dụ về cách Máy chủ đặt phòng xử lý tính chất bất biến:
Phản hồi HTTP CreateBooking thành công sẽ bao gồm thông tin về lượt đặt phòng đã tạo. Trong một số trường hợp, khoản thanh toán được xử lý trong quy trình đặt vé. Nếu cùng một CreateBookingRequest được nhận lần thứ hai với cùng một idempotency_token, thì bạn phải trả về cùng một CreateBookingResponse. Không tạo yêu cầu đặt phòng thứ hai và người dùng chỉ bị tính phí một lần (nếu có).
Yêu cầu về tính chất bất biến áp dụng cho tất cả các phương thức làm thay đổi trạng thái.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Thiếu thông tin tôi cần","missingTheInformationINeed","thumb-down"],["Quá phức tạp/quá nhiều bước","tooComplicatedTooManySteps","thumb-down"],["Đã lỗi thời","outOfDate","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Vấn đề về mẫu/mã","samplesCodeIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 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."]]
