तीसरा चरण: वेटलिस्ट बुकिंग सर्वर लागू करना

आपको एक बुकिंग सर्वर बनाना होगा, ताकि ऐक्शन सेंटर आपकी ओर से बुकिंग बनाने और अपडेट करने के लिए कॉलबैक कर सके.

• बुकिंग के लिए वेटलिस्ट में शामिल होने की सुविधा लागू करना. इसका इस्तेमाल तब किया जाता है, जब आपने रिज़र्वेशन की वेटलिस्ट के पायलट कार्यक्रम में हिस्सा लिया हो. इससे Actions Center को, उपयोगकर्ता की ओर से, प्रतीक्षा का अनुमान पाने और वेटलिस्ट में एंट्री बनाने में मदद मिलती है.
• स्टैंडर्ड तरीके से लागू करना. इससे ऐक्शन सेंटर, उपयोगकर्ता की ओर से आपके साथ अपॉइंटमेंट, बुकिंग, और रिज़र्वेशन बना सकता है. बुकिंग की पूरी प्रोसेस को इंटिग्रेट करने के लिए, बुकिंग सर्वर लागू करने का तरीका जानने के लिए, कृपया बुकिंग सर्वर लागू करना लेख पढ़ें.

अपने सैंडबॉक्स और प्रोडक्शन बुकिंग सर्वर से कनेक्शन को कॉन्फ़िगर करने का तरीका जानने के लिए, पार्टनर पोर्टल दस्तावेज़ देखें.

REST API इंटरफ़ेस लागू करना

REST के आधार पर एपीआई इंटरफ़ेस लागू करें. इससे Google, एचटीटीपी के ज़रिए बुकिंग सर्वर के अनुरोध भेज सकता है.

शुरू करने के लिए, डेवलपमेंट या सैंडबॉक्स बुकिंग सर्वर सेट अप करें. इसे Actions Center के सैंडबॉक्स इनवायरनमेंट से कनेक्ट किया जा सकता है. सैंडबॉक्स सर्वर की पूरी जांच करने के बाद ही, प्रोडक्शन एनवायरमेंट पर जाएं.

तरीके

बुकिंग सर्वर के हर टाइप के लिए, आपके पास एपीआई के अलग-अलग तरीकों का एक सेट होना चाहिए. इसके अलावा, एपीआई लागू करने के लिए, सेवा की परिभाषा को प्रोटोटैप फ़ॉर्मैट में डाउनलोड किया जा सकता है. यहां दी गई टेबल में, सेवा को लागू करने के हर तरीके के बारे में बताया गया है. साथ ही, इनमें सेवा के प्रोटो फ़ॉर्मैट के लिंक भी शामिल हैं.

वेटलिस्ट लागू करना
वेटलिस्ट की सेवा की परिभाषा. प्रोटो सेवा की परिभाषा वाली फ़ाइल डाउनलोड करें.

तरीका	एचटीटीपी अनुरोध
HealthCheck	GET /v3/HealthCheck/
BatchGetWaitEstimates	POST /v3/BatchGetWaitEstimates/
CreateWaitlistEntry	POST /v3/CreateWaitlistEntry/
GetWaitlistEntry	POST /v3/GetWaitlistEntry/
DeleteWaitlistEntry	POST /v3/DeleteWaitlistEntry/

एपीआई के रिसॉर्स

वेटलिस्ट

वेटिंगलिस्ट के आधार पर बुकिंग की सुविधा लागू करने के लिए, इन संसाधनों का इस्तेमाल किया जाता है:

• WaitEstimate: किसी खास पार्टी के साइज़ और कारोबारी या कंपनी के लिए, इंतज़ार का अनुमान.
• WaitlistEntry: वेटलिस्ट में उपयोगकर्ता की एंट्री.

फ़्लो: वेटलिस्ट में एंट्री बनाना

इस सेक्शन में, बुकिंग के वेटलिस्ट इंटिग्रेशन के लिए बुकिंग बनाने का तरीका बताया गया है.

जब कोई उपयोगकर्ता वेटलिस्ट में अपनी जानकारी डालता है, तो Google आपको उपयोगकर्ता का नाम, उपनाम, फ़ोन नंबर, और ईमेल पता भेजता है. यह ईमेल पता, उपयोगकर्ता के Google खाते का ही होता है. साथ ही, इसे यूनीक आइडेंटिफ़ायर माना जाता है. आपके हिसाब से, इस वेटलिस्ट को मेहमान के तौर पर चेकआउट करने की सुविधा के तौर पर माना जाना चाहिए. ऐसा इसलिए, क्योंकि Reserve with Google आपके सिस्टम में उपयोगकर्ता के खाते को नहीं देख सकता. पक्का करें कि प्रतीक्षा सूची में मौजूद आखिरी एंट्री, आपके प्रतीक्षा सूची वाले सिस्टम से मिली व्यापारियों/कंपनियों की एंट्री से मेल खाती हो.

सुरक्षा और पुष्टि

बुकिंग सर्वर से सभी तरह का कम्यूनिकेशन एचटीटीपीएस के ज़रिए होता है. इसलिए, यह ज़रूरी है कि आपके सर्वर के पास एक मान्य TLS सर्टिफ़िकेट हो, जो उसके डोमेन नेम से मेल खाता हो. हमारा सुझाव है कि अपने सर्वर को सेट अप करने के लिए, एसएसएल/TLS की पुष्टि करने वाले ऐसे टूल का इस्तेमाल करें जो बिना किसी शुल्क के उपलब्ध हों. जैसे, Qualys का एसएसएल सर्वर टेस्ट.

Google आपके बुकिंग सर्वर से जो भी अनुरोध करेगा उनकी पुष्टि, एचटीटीपी बेसिक पुष्टि करने की सुविधा का इस्तेमाल करके की जाएगी. बुकिंग सर्वर के लिए, बुनियादी पुष्टि करने वाले क्रेडेंशियल (उपयोगकर्ता नाम और पासवर्ड) को पार्टनर पोर्टल में, बुकिंग सर्वर कॉन्फ़िगरेशन पेज पर डाला जा सकता है. पासवर्ड हर छह महीने में बदले जाने चाहिए.

स्केलेटन लागू करने के उदाहरण

शुरू करने के लिए, Node.js और Java फ़्रेमवर्क के लिए लिखे गए, बुकिंग सर्वर के इन सैंपल स्केलेटन को देखें:

• Node.js स्केलेटन js-maps-booking-rest-server-v3-skeleton
• Java स्केलेटन java-maps-booking-rest-server-v3-skeleton

इन सर्वर ने REST तरीकों को स्टब कर दिया है.

ज़रूरी शर्तें

एचटीटीपी गड़बड़ियां और कारोबार के लॉजिक से जुड़ी गड़बड़ियां

जब आपका बैकएंड एचटीटीपी अनुरोधों को हैंडल करता है, तो दो तरह की गड़बड़ियां हो सकती हैं.

• इंफ़्रास्ट्रक्चर या गलत डेटा से जुड़ी गड़बड़ियां
  • इन गड़बड़ियों को क्लाइंट को, एचटीटीपी की गड़बड़ी के स्टैंडर्ड कोड के साथ दिखाएं. एचटीटीपी स्टेटस कोड की पूरी सूची देखें.
• कारोबारी नियम से जुड़ी गड़बड़ियां
  • एचटीटीपी स्टेटस कोड को 200 OK पर सेट करें और रिस्पॉन्स बॉडी में, कारोबारी नियम से जुड़ी गड़बड़ी के बारे में बताएं. अलग-अलग तरह के सर्वर लागू करने पर, आपको कारोबारी लॉजिक से जुड़ी अलग-अलग तरह की गड़बड़ियां दिख सकती हैं.

बुकिंग वेटलिस्ट इंटिग्रेशन के लिए, बिज़नेस लॉजिक से जुड़ी गड़बड़ियां वेटलिस्ट के बिज़नेस लॉजिक में गड़बड़ी में कैप्चर की जाती हैं. साथ ही, इन्हें एचटीटीपी रिस्पॉन्स में दिखाया जाता है. संसाधन बनाते समय, कारोबार के लॉजिक से जुड़ी गड़बड़ियां हो सकती हैं. उदाहरण के लिए, CreateWaitlistEntry मेथड को हैंडल करते समय. उदाहरणों में ये चीज़ें शामिल हैं, लेकिन इनके अलावा और भी चीज़ें शामिल हो सकती हैं:

• ABOVE_MAX_PARTY_SIZE का इस्तेमाल तब किया जाता है, जब वेटलिस्ट में शामिल होने का अनुरोध, कारोबारी की तय की गई सीमा से ज़्यादा हो.
• MERCHANT_CLOSED का इस्तेमाल तब किया जाता है, जब वेटलिस्ट खुली न हो, क्योंकि व्यापारी/कंपनी/कारोबारी की दुकान पहले से ही बंद हो.

एक बार की गई कार्रवाई दोबारा न हो

नेटवर्क पर कम्यूनिकेशन हमेशा भरोसेमंद नहीं होता. अगर कोई जवाब नहीं मिलता है, तो Google एचटीटीपी अनुरोधों को फिर से कोशिश कर सकता है. इस वजह से, राज्य में बदलाव करने वाले सभी तरीकों को एक जैसा होना चाहिए:

• CreateWaitlistEntry
• DeleteWaitlistEntry

DeleteWaitlistEntry को छोड़कर, हर अनुरोध मैसेज के लिए, अनुरोध की यूनीक पहचान करने के लिए, एक जैसे मैसेज को दोबारा भेजने से जुड़े टोकन शामिल किए जाते हैं. इससे, एक अनुरोध बनाने के मकसद से दोबारा किए गए REST कॉल और दो अलग-अलग अनुरोधों के बीच अंतर किया जा सकता है. DeleteWaitlistEntry को उनके वेटलिस्ट एंट्री आईडी से अलग-अलग पहचाना जाता है. इसलिए, उनके अनुरोधों में कोई डुप्लीकेट आईडी टोकन शामिल नहीं किया जाता.

बुकिंग सर्वर, एक ही बुकिंग के लिए एक से ज़्यादा अनुरोधों को कैसे हैंडल करते हैं, इसके कुछ उदाहरण यहां दिए गए हैं:

• CreateWaitlistEntry एचटीटीपी रिस्पॉन्स में, वेटलिस्ट में जोड़ा गया एंट्री आईडी शामिल होता है. अगर एक ही CreateWaitlistEntryRequest को दूसरी बार (एक ही idempotency_token के साथ) मिलता है, तो वही CreateWaitlistEntryResponse लौटाया जाना चाहिए. कोई दूसरी प्रतीक्षा सूची वाली एंट्री नहीं बनाई जाती और कोई गड़बड़ी नहीं दिखती.

  ध्यान दें कि अगर CreateWaitlistEntry की कोशिश पूरी नहीं होती है और वही अनुरोध फिर से भेजा जाता है, तो इस मामले में आपके बैकएंड को फिर से कोशिश करनी चाहिए.

एक ही काम दो बार न हो, यह शर्त उन सभी तरीकों पर लागू होती है जो स्थिति में बदलाव करते हैं.