تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
لإكمال مهمة CreateBooking Ready في مرحلة الإنجاز، عليك إنشاء طريقة CreateBooking وتسليمها بنجاح. يتم استدعاء هذا الإجراء عندما يحاول المستخدم إنشاء حجز. في حال إنشاء حجز ناجح، يتضمّن الردّ booking_id فريدًا للإشارة إلى الحجز في الطلبات أو التعديلات المستقبلية.
متطلبات مهمة CreateBooking
10 استجابات ناجحة CreateBooking بمعدّل خطأ أقل من %10
أساسيات CreateBooking
عندما يبدأ المستخدم عملية حجز، يتم إرسال طلب CreateBooking إلى خادم الحجز الخاص بالشريك. تشير الاستجابة للطلب إلى نجاح الحجز أو تعذّره. في حال حدوث خطأ في الحجز، يجب أن يتضمّن الردّ خطأ منطق النشاط التجاري الذي أدّى إلى حدوث الخطأ. على سبيل المثال، أصبح الموعد غير متاح أو سبق أن حجزه المستخدم نفسه.
عندما ينشئ مستخدم حجزًا، ترسل إليك Google اسم المستخدم واسم عائلته ورقم هاتفه وعنوان بريده الإلكتروني. لمزيد من المعلومات، يُرجى الاطّلاع على
سياسة مطابقة الحسابات وإنشائها.
التكرار
لا يمكن الاعتماد دائمًا على الاتصال عبر الشبكة، ويمكن أن تعيد Google محاولة طلبات HTTP إذا لم يتم تلقّي أي ردّ. لهذا السبب، يجب أن تكون جميع الطرق التي تغيّر الحالة متكررة:
CreateBooking
UpdateBooking
بالنسبة إلى كل رسالة طلب، باستثناء UpdateBooking، يتم تضمين رموز مميّزة لضمان عدم تكرار الطلب من أجل تحديد الطلب بشكل فريد. يتيح لك ذلك التمييز بين إعادة محاولة إجراء طلب REST، مع النية لإنشاء طلب واحد وطلبَين منفصلَين. تساعد المعرّفات الخاصة بإدخالات الحجز في UpdateBooking على تحديدها بشكل فريد، لذا لا يتم تضمين رمز مميّز لضمان عدم تكرار الطلبات في طلباتها.
في ما يلي بعض الأمثلة على كيفية تعامل خوادم الحجز مع خاصية التكرار:
تتضمّن استجابة
CreateBooking
HTTP الناجحة الحجز الذي تم إنشاؤه. في بعض الحالات، تتم معالجة الدفع كجزء من عملية الحجز. إذا تم تلقّي CreateBookingRequest نفسها
للمرة الثانية مع idempotency_token نفسها، يجب عرض CreateBookingResponse نفسها. لن يتم إنشاء حجز ثانٍ، وسيتم تحصيل الرسوم من المستخدم مرة واحدة فقط، إذا كان ذلك منطبقًا.
ينطبق شرط التكرار على جميع الطرق التي تغيّر الحالة.
تاريخ التعديل الأخير: 2025-07-26 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-07-26 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],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."]]
