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

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

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

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

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

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

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

तरीके

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

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

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

बुकिंग करें

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

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

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

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

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

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

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

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

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

नमूने के तौर पर कंकाल लागू करना

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

इन सर्वर में, REST के तरीकों का इस्तेमाल नहीं किया जा सकता.

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

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

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

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

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

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

असमानता

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

  • CreateBooking
  • UpdateBooking

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

यहां कुछ उदाहरण दिए गए हैं कि बुकिंग सर्वर, एक जैसा नहीं है:

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

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

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