बुकिंग सर्वर लागू करना

आपकी ओर से बुकिंग बनाने और अपडेट करने के लिए, Reserve with Google को कॉल करने की अनुमति देने के लिए, आपको बुकिंग सर्वर को सेट अप करना होगा.

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

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

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

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

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

तरीके

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

मानक कार्यान्वयन
मानक सेवा परिभाषा प्रोटो सेवा परिभाषा फ़ाइल डाउनलोड करें.
तरीका एचटीटीपी अनुरोध
स्वास्थ्य की जांच पाएं /v3/HealthCheck/
BatchAvailabilityLookup POST /v3/BatchAvailabilityLookup/
किताब बनाना पोस्ट /v3/CreateBooking/
UpdateBooking POST /v3/UpdateBooking/
बुकिंग की स्थिति पाना POST /v3/GetBookingStatus/
लिस्ट बुकिंग पोस्ट /v3/Listबुकिंग/

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

बुकिंग करें

मानक लागू करने में नीचे दिए गए संसाधन के प्रकार इस्तेमाल किए जाते हैं:

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

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

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

इमेज 1: किसी स्लॉट से बुकिंग बनाने के लिए वर्कफ़्लो
पहली इमेज: स्लॉट से बुकिंग बनाने के लिए वर्कफ़्लो

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

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

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

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

नमूने के साथ स्केलेटन लागू करना

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

इन सर्वर ने REST के तरीके निकाल दिए हैं.

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

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

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

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

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

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

कम समय के लिए

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

  • CreateBooking
  • UpdateBooking

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

नीचे कुछ उदाहरण दिए गए हैं कि बुकिंग सर्वर, परफ़ॉर्मेंस की स्थिति से कैसे निपटते हैं:

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

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

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