כדי להשלים את משימת אבן הדרך CreateBooking מוכן, צריך ליצור ולספק בהצלחה את CreateBooking השיטה. המערכת קוראת לשיטה הזו כשמשתמש מנסה ליצור הזמנה. אם נוצרת הזמנה מוצלחת, התשובה כוללת booking_id ייחודי שאפשר להשתמש בו כדי להתייחס להזמנה בבקשות או בעדכונים עתידיים.
דרישות ליצירת משימות ב-CreateBooking
- 10
CreateBookingבקשות ב-Sandbox עם שיעור הצלחה של 90% ומעלה. - 3 בקשות
CreateBookingבסביבת הייצור עם שיעור הצלחה של 90% ומעלה.
יסודות של CreateBooking
כשמשתמש יוזם הזמנה, בקשת CreateBooking נשלחת לשרת ההזמנות של השותף. התשובה לבקשה מציינת אם ההזמנה בוצעה בהצלחה או נכשלה. אם ההזמנה נכשלת, התגובה צריכה לכלול את שגיאת הלוגיקה העסקית שגרמה לכשל. לדוגמה, אם המשבצת הפכה ללא זמינה או שהמשבצת כבר הוזמנה על ידי אותו משתמש.
כשמשתמש יוצר הזמנה, Google שולחת לכם את השם הפרטי, שם המשפחה, מספר הטלפון וכתובת האימייל של המשתמש. מידע נוסף זמין במאמר בנושא מדיניות בנושא התאמה ויצירה של חשבונות.
האידמפוטנטיות
התקשורת ברשת לא תמיד אמינה, ו-Google יכולה לנסות שוב בקשות HTTP אם לא מתקבלת תגובה. לכן, כל השיטות שמשנות את המצב צריכות להיות אידמפוטנטיות:
CreateBookingUpdateBooking
לכל הודעת בקשה, חוץ מ-UpdateBooking, מצורפים טוקנים של אידמפוטנטיות כדי לזהות את הבקשה באופן ייחודי. כך אפשר להבדיל בין ניסיון חוזר של קריאת REST, עם כוונה ליצור בקשה אחת, לבין שתי בקשות נפרדות. מזהי הזמנה של UpdateBooking עוזרים לזהות אותם באופן ייחודי, ולכן לא נכלל אסימון אידמפוטנטיות בבקשות שלהם.
הנה כמה דוגמאות לאופן שבו שרתי הזמנות מטפלים באידמפוטנטיות:
תשובת HTTP מוצלחת של
CreateBookingכוללת את ההזמנה שנוצרה. במקרים מסוימים, התשלום מתבצע כחלק מתהליך ההזמנה. אם מתקבלת אותהCreateBookingRequestבפעם השנייה עם אותוidempotency_token, צריך להחזיר את אותוCreateBookingResponse. לא נוצרת הזמנה שנייה, ואם רלוונטי, המשתמש מחויב בדיוק פעם אחת.
הדרישה לאידמפוטנטיות חלה על כל השיטות שמשנות את המצב.