चौथा चरण: बुकिंग सर्वर लागू करना

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

• मानक लागू करना. इससे कार्रवाई केंद्र को उपयोगकर्ता की ओर से आपके साथ अपॉइंटमेंट, बुकिंग, और बुकिंग करने की सुविधा मिलती है.

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

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

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

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

तरीके

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

मानक कार्यान्वयन
स्टैंडर्ड सर्विस डेफ़िनिशन प्रोटो सर्विस डेफ़िनिशन की फ़ाइल डाउनलोड करें.

तरीका	एचटीटीपी अनुरोध
HealthCheck	जीईटी /v3/HealthCheck/
BatchAvailabilityLookup	पोस्ट /v3/BatchAvailabilitylookup/
CreateBooking	पोस्ट /v3/CreateBooking/
UpdateBooking	पोस्ट /v3/UpdateBooking/
GetBookingStatus	पोस्ट /v3/GetBookingStatus/
ListBookings	पोस्ट /v3/ListBookings/

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

बुकिंग करें

मानक तरीके से लागू करने में, यहां दिए गए रिसॉर्स टाइप का इस्तेमाल किया जाता है:

• स्लॉट: एक इन्वेंट्री स्लॉट.
• बुकिंग: किसी इन्वेंट्री स्लॉट के लिए अपॉइंटमेंट.

फ़्लो: बुकिंग बनाएं

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• SLOT_UNAVAILABLE का इस्तेमाल तब किया जाता है, जब अनुरोध किया गया स्लॉट अब उपलब्ध न हो.
• अगर दिए गए क्रेडिट कार्ड को स्वीकार नहीं किया जाता है, तो PAYMENT_ERROR_CARD_TYPE_REJECTED का इस्तेमाल किया जाता है.

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

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

• CreateBooking
• UpdateBooking

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

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

• सफल CreateBooking एचटीटीपी रिस्पॉन्स में, की गई बुकिंग शामिल होती है. कुछ मामलों में, बुकिंग फ़्लो के तहत ही पेमेंट किया जाता है. अगर एक ही CreateBookingRequest दूसरी बार मिलता है (उसी idempotency_token के साथ), तो वही CreateBookingResponse लौटाया जाना चाहिए. कोई दूसरी बुकिंग नहीं बनाई जाती और लागू होने पर, उपयोगकर्ता से सिर्फ़ एक बार शुल्क लिया जाता है.

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

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