כדי ליצור ולעדכן הזמנות בשמכם, צריך ליצור שרת הזמנות כדי לאפשר למרכז הפעולות לבצע קריאות חוזרות (callback).
- הטמעת רשימות ההמתנה להזמנות. המידע הזה משמש להשתתפות בתוכנית הפיילוט Reservationswaitlists. כך מרכז הפעולות יכול לאחזר אומדני המתנה וליצור רשומות של רשימות המתנה בשם המשתמש.
- ההטמעה הסטנדרטית. ההרשאה הזו מאפשרת למרכז הפעולות ליצור איתך פגישות, הזמנות והזמנות בשם המשתמש. כדי להטמיע שרת הזמנות לשילוב הזמנות מקצה לקצה, כדאי לעיין במאמר הטמעת שרת ההזמנות.
במסמכי התיעוד של פורטל השותפים מוסבר איך להגדיר את החיבור לארגז החול ולשרתי ההזמנות בסביבת הייצור.
הטמעה של ממשק API ל-REST
מטמיעים ממשק API שמבוסס על REST. כך Google יכולה לשלוח בקשות משרת הזמנות באמצעות HTTP.
כדי להתחיל, צריך להגדיר שרת הזמנות של פיתוח או ארגז חול שאפשר לחבר לסביבת ארגז החול של מרכז הפעולות. צריך לעבור לסביבת ייצור רק אחרי ששרת ה-Sandbox נבדק בצורה מלאה.
שיטות
לכל סוג של שרת הזמנות נדרשת קבוצה שונה של שיטות API בצד שלך. אפשר גם להוריד את הגדרת השירות בפורמט אב כדי להתחיל בהטמעת ה-API. בטבלאות הבאות מוצגות השיטות לכל הטמעה וכוללות קישורים לפורמטים של מאפייני השירות.
הטמעת רשימת המתנה |
---|
הגדרת השירות ברשימת ההמתנה. מורידים את קובץ ההגדרה של שירות האב. |
שיטה | בקשת HTTP |
---|---|
HealthCheck | GET /v3/HealthCheck/ |
BatchGetWaitEstimates | POST /v3/BatchGetPendingEstimates/ |
CreateWaitlistEntry | POST /v3/CreateWaitlistEntry/ |
GetWaitlistEntry | POST /v3/GetWaitlistEntry/ |
DeleteWaitlistEntry | POST /v3/DeletewaitlistEntry/ |
משאבי API
רשימת המתנה
המשאבים הבאים משמשים להטמעת הזמנות שמבוססות על רשימות המתנה:
- WaitEstimate: הערכת המתנה לפי מספר סועדים ספציפי ולמוכר ספציפי.
- WaitlistEntry: הצטרפות של משתמש לרשימת ההמתנה.
תהליך: יצירת רשומה של רשימת המתנה
בקטע הזה מוסבר איך ליצור הזמנה לשילוב של Reservationswaits.
![איור 2: תהליך העבודה ליצירת רשומה ברשימת ההמתנה](https://developers.google.cn/static/actions-center/images/waitlists/rest_api_v3_waitlist_flow.png?authuser=9&hl=he)
כשהמשתמש יוצר רשומה ברשימת ההמתנה, Google שולחת לך את השם הפרטי, שם המשפחה, מספר הטלפון וכתובת האימייל שלו. כתובת האימייל זהה לחשבון Google של המשתמש, והמערכת מתייחסת אליה כמזהה ייחודי. מנקודת המבט שלך, יש להתייחס לרשימת ההמתנה הזו כאל תשלום כאורח, כי'Google הזמנת מקומות' לא יכול לחפש במערכת שלך את חשבון המשתמש. צריך לוודא שהרשומה הסופית ברשימת ההמתנה נראית זהה לרשומות של המוכרים שמגיעים ממערכת רשימות ההמתנה שלך.
אבטחה ואימות
כל התקשורת לשרת ההזמנות מתבצעת באמצעות HTTPS, לכן חשוב שלשרת יהיה אישור TLS חוקי שתואם לשם ה-DNS שלו. כדי לעזור בהגדרת השרת, אנחנו ממליצים להשתמש בכלי אימות SSL/TLS שזמין בחינם, כמו בדיקת שרת SSL של Qualys.
כל הבקשות ש-Google שולחת לשרת ההזמנות יאומתו באמצעות אימות בסיסי של HTTP. אפשר להזין את פרטי הכניסה הבסיסיים לאימות (שם משתמש וסיסמה) עבור שרת ההזמנות בדף ההגדרה של שרת ההזמנות בפורטל השותפים. יש להחליף סיסמאות כל שישה חודשים.
הטמעות של שלד לדוגמה
כדי להתחיל, כדאי לבדוק את השלדים לדוגמה הבאים של שרת הזמנות, שנכתבו עבור Node.js ו-Java frameworks:
- שלד של Node.js js-maps-booking-rest-server-v3-skeleton
- שלד של Java java-maps-booking-rest-server-v3-skeleton
השרתים האלה מצמצמים את שיטות ה-REST.
דרישות
שגיאות HTTP ושגיאות לוגיקה עסקית
כשהקצה העורפי מטפל בבקשות HTTP, עשויות להתרחש שגיאות משני סוגים.
- שגיאות שקשורות לתשתית או לנתונים שגויים
- מחזירים את השגיאות האלה ללקוח עם קודים רגילים של שגיאות HTTP. כאן תוכלו לקרוא את הרשימה המלאה של קודי המצב של HTTP.
- שגיאות שקשורות ללוגיקה העסקית
- החזרת קוד סטטוס HTTP המוגדר ל-
200
OK, וציון הכשל בלוגיקה העסקית בגוף התגובה. יש סוגים שונים של שגיאות לוגיקה עסקיות שעשויות להופיע בהתאם לסוגים השונים של הטמעות שרתים.
- החזרת קוד סטטוס HTTP המוגדר ל-
בשילוב של רשימות ההמתנה של ההזמנות, שגיאות הלוגיקה העסקיות מתועדות בכשל בלוגיקה העסקית של רשימת ההמתנה, והן מוחזרות בתגובת HTTP. יכול להיות שתיתקלו בשגיאות לוגיות עסקיות כשיוצרים משאב, למשל כשמטפלים בשיטה CreateWaitlistEntry
. דוגמאות לכך כוללות, בין היתר:
- המספר
ABOVE_MAX_PARTY_SIZE
משמש כשהמספר המבוקש של רשימת ההמתנה חורג מהגודל המקסימלי שנקבע למוכר על ידי המוכר. MERCHANT_CLOSED
נמצא בשימוש כשרשימת ההמתנה לא פתוחה כי המוכר כבר סגור.
אי-ספיקות
התקשורת ברשת לא תמיד מהימנה, ו-Google עשויה לנסות שוב בקשות HTTP אם לא מתקבלת תשובה. מסיבה זו, כל השיטות שמשנים את המצב חייבות להיות אידמפונטיות:
CreateWaitlistEntry
DeleteWaitlistEntry
לכל הודעת בקשה פרט ל-DeleteWaitlistEntry
, נכללים אסימוני זהות כדי לזהות את הבקשה
באופן ייחודי. כך ניתן להבחין בין קריאה חוזרת ל-REST מתוך כוונה ליצור בקשה אחת לבין שתי בקשות נפרדות.
DeleteWaitlistEntry
מזוהה
באופן ייחודי לפי מזהי הרשומה ברשימת ההמתנה שלו, בהתאמה, ולכן
לא נכלל אסימון זהות בבקשות שלו.
בהמשך מפורטות כמה דוגמאות לאופן שבו שרתי הזמנות מטפלים בהעברת נתונים:
תגובת HTTP של
CreateWaitlistEntry
שבוצעה בהצלחה כוללת את מזהה הרשומה שנוצר לרשימת ההמתנה. אם אותוCreateWaitlistEntryRequest
מתקבל פעם שנייה (עם אותוidempotency_token
), יש להחזיר את אותוCreateWaitlistEntryResponse
. לא נוצרה רשומה שנייה לרשימת ההמתנה ולא מוחזרת שגיאה.הערה: אם הניסיון של
CreateWaitlistEntry
נכשל ואותה הבקשה נשלחת מחדש, הקצה העורפי צריך לנסות שוב במקרה הזה.
הדרישה של יכולת הזיהוי חלה על כל השיטות שמשתנות מצב.