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

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

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

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

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

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

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

तरीके

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

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

तरीका	एचटीटीपी अनुरोध
HealthCheck	GET /v3/HealthCheck/
BatchAvailabilityLookup	POST /v3/BatchAvailabilityLookup/
CreateBooking	POST /v3/CreateBooking/
UpdateBooking	POST /v3/UpdateBooking/
GetBookingStatus	POST /v3/GetBookingStatus/
ListBookings	POST /v3/ListBookings/

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

बुकिंग करें

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

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

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

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

जब कोई उपयोगकर्ता बुकिंग करता है, तो 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 पर सेट करें और रिस्पॉन्स बॉडी में, कारोबारी नियम से जुड़ी गड़बड़ी के बारे में बताएं. अलग-अलग तरह के सर्वर लागू करने पर, आपको कारोबारी लॉजिक से जुड़ी अलग-अलग तरह की गड़बड़ियां दिख सकती हैं.

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

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

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

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

• CreateBooking
• UpdateBooking

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

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

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

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

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