קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
כדי להשלים את המשימה CreateBooking מוכנות להשקה, צריך ליצור ולספק את CreateBooking השיטה בהצלחה. המערכת קוראת לשיטה הזו כשמשתמש מנסה ליצור הזמנה. אם נוצרת הזמנה מוצלחת, התשובה כוללת booking_id ייחודי שאפשר להשתמש בו כדי להתייחס להזמנה בבקשות או בעדכונים עתידיים.
דרישות ליצירת משימות של הזמנת תור
10 תגובות מוצלחות של CreateBooking עם שיעור שגיאות של פחות מ-10%.
יסודות של CreateBooking
כשמשתמש יוזם הזמנה, בקשת CreateBooking נשלחת לשרת ההזמנות של השותף. התשובה לבקשה מציינת אם ההזמנה בוצעה בהצלחה או נכשלה. אם ההזמנה נכשלת, התגובה צריכה לכלול את שגיאת הלוגיקה העסקית שגרמה לכשל. לדוגמה, המשבצת הפכה ללא זמינה או שהיא כבר הוזמנה על ידי אותו משתמש.
כשמשתמש יוצר הזמנה, Google שולחת לכם את השם הפרטי, שם המשפחה, מספר הטלפון וכתובת האימייל של המשתמש. מידע נוסף זמין במאמר בנושא מדיניות בנושא התאמה ויצירה של חשבונות.
האידמפוטנטיות
התקשורת ברשת לא תמיד אמינה, ו-Google יכולה לנסות שוב לשלוח בקשות HTTP אם לא מתקבלת תשובה. לכן, כל השיטות שמשנות את המצב צריכות להיות אידמפוטנטיות:
CreateBooking
UpdateBooking
לכל הודעת בקשה, חוץ מ-UpdateBooking, מצורפים טוקנים של אידמפוטנטיות כדי לזהות את הבקשה באופן ייחודי. כך אפשר להבדיל בין ניסיון חוזר של קריאת REST, עם כוונה ליצור בקשה אחת, לבין שתי בקשות נפרדות. מזהי הזמנות הרלוונטיים של UpdateBooking עוזרים לזהות אותם באופן ייחודי, ולכן לא נכלל אסימון אידמפוטנטיות בבקשות שלהם.
הנה כמה דוגמאות לאופן שבו שרתי ההזמנות מטפלים באידמפוטנטיות:
תשובת HTTP מוצלחת של CreateBooking כוללת את ההזמנה שנוצרה. במקרים מסוימים, התשלום מתבצע כחלק מתהליך ההזמנה. אם מתקבל אותו CreateBookingRequest בפעם השנייה עם אותו idempotency_token, צריך להחזיר את אותו CreateBookingResponse. לא נוצרת הזמנה שנייה, ואם רלוונטי, המשתמש מחויב בדיוק פעם אחת.
הדרישה לאידמפוטנטיות חלה על כל השיטות שמשנות את המצב.
[[["התוכן קל להבנה","easyToUnderstand","thumb-up"],["התוכן עזר לי לפתור בעיה","solvedMyProblem","thumb-up"],["סיבה אחרת","otherUp","thumb-up"]],[["חסרים לי מידע או פרטים","missingTheInformationINeed","thumb-down"],["התוכן מורכב מדי או עם יותר מדי שלבים","tooComplicatedTooManySteps","thumb-down"],["התוכן לא עדכני","outOfDate","thumb-down"],["בעיה בתרגום","translationIssue","thumb-down"],["בעיה בדוגמאות/בקוד","samplesCodeIssue","thumb-down"],["סיבה אחרת","otherDown","thumb-down"]],["עדכון אחרון: 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."]]
