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

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

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

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

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

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

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

तरीके

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

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

तरीका	एचटीटीपी अनुरोध
HealthCheck	जीईटी /v3/HealthCheck/
BatchGetWaitEstimates	POST /v3/BatchGet क्लाइंटटेस्ट/
CreateWaitlistEntry	पोस्ट /v3/Create WaitlistEntry/
GetWaitlistEntry	पोस्ट /v3/Get WaitlistEntry/
DeleteWaitlistEntry	पोस्ट /v3/DeleteValidlistEntry/

एपीआई के संसाधन

वेटलिस्ट

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

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

फ़्लो: वेटलिस्ट में शामिल होने का विकल्प बनाएं

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

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

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

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

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

सैंपल स्केलेटन को लागू करना

शुरू करने के लिए, Node.js और Java फ़्रेमवर्क के लिए लिखे गए बुकिंग सर्वर के नमूने के नीचे दिए गए कंकाल देखें:

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

इन सर्वर पर REST मेथड का एक हिस्सा मौजूद है.

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

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

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

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

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

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

पहचान न कर पाना

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

• CreateWaitlistEntry
• DeleteWaitlistEntry

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

यहां कुछ उदाहरण दिए गए हैं कि बुकिंग सर्वर, पहचान की पुष्टि करने के तरीके को कैसे मैनेज करते हैं:

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

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

आईडी एम्पॉटेंसी की ज़रूरी शर्त, स्थिति में बदलाव करने वाले सभी तरीकों पर लागू होती है.