अपनी तरफ़ से बुकिंग सर्वर सेट अप करने से, कार्रवाई केंद्र को उपयोगकर्ता की ओर से आपके साथ अपॉइंटमेंट / बुकिंग / बुकिंग करने की अनुमति मिल जाएगी.
gRPC के आधार पर एपीआई इंटरफ़ेस लागू करें
कृपया ध्यान दें: सभी नए पार्टनर को gRPC API के बजाय, REST API इंटरफ़ेस का इस्तेमाल करना चाहिए.
gRPC के आधार पर एपीआई इंटरफ़ेस लागू करें. इससे Google, बुकिंग के अनुरोध भेज पाता है. एपीआई प्लैटफ़ॉर्म को gRPC के प्रोटोबफ़ पर आधारित आईडीएल का इस्तेमाल करके तय किया जाता है.
हम अपने नए पार्टनर को, सुझाया गया एपीआई वर्शन 2 लागू करने के लिए कहते हैं. पार्टनर अपने इंफ़्रास्ट्रक्चर के लिए सबसे सही यूआरएल और पोर्ट चुन सकते हैं.
इस सेक्शन में, एपीआई v2 के सुझाए गए सेट के बारे में बताया गया है. यह उन पार्टनर पर लागू होता है जिन्होंने एपीआई v0 को लागू नहीं किया है. एपीआई v0 लागू करने वाले हमारे मौजूदा पार्टनर, ज़्यादा जानकारी के लिए कार्रवाई केंद्र से संपर्क करें.
एपीआई लागू करने के लिए, नीचे दिए गए प्रोटो फ़ॉर्मैट में सेवा की परिभाषा डाउनलोड करें.
एपीआई के संसाधन
कृपया यहां दिए गए रिसॉर्स टाइप के बारे में जानें, जिनका इस्तेमाल इस लागू करने में किया जाएगा:
तरीके
एपीआई के इन तरीकों को gRPC सर्वर पर लागू करने के लिए ज़रूरी है:
ये पांच तरीके, BookingService के आरपीसी के ज़रूरी सेट को तय करते हैं:
// Manages slot availability, leases and bookings for an inventory of
// appointments
service BookingService {
// Gets availability information for an appointment slot
rpc CheckAvailability(CheckAvailabilityRequest)
returns (CheckAvailabilityResponse) {}
// Creates a booking
rpc CreateBooking(CreateBookingRequest) returns (CreateBookingResponse) {}
// Updates an existing booking
rpc UpdateBooking(UpdateBookingRequest) returns (UpdateBookingResponse) {}
// Gets status for an existing booking
rpc GetBookingStatus(GetBookingStatusRequest)
returns (GetBookingStatusResponse) {}
// Lists all upcoming bookings for a user
rpc ListBookings(ListBookingsRequest) returns (ListBookingsResponse) {}
}
फ़्लो: बुकिंग बनाएं
बुकिंग बनाते समय Google, पार्टनर को उपयोगकर्ता का दिया गया नाम, सरनेम, फ़ोन नंबर, और ईमेल पता भेजेगा. पार्टनर के हिसाब से, इसे मेहमान के तौर पर चेकआउट करने की तरह माना जाना चाहिए. ऐसा इसलिए, क्योंकि कार्रवाई केंद्र के पास पार्टनर के सिस्टम में उपयोगकर्ता के खाते को देखने का कोई तरीका नहीं होता. पार्टनर के सिस्टम में फ़ाइनल बुकिंग को उसी तरह से दिखाया जाना चाहिए जैसा पार्टनर के बुकिंग सिस्टम पर होता है.
Java में स्केलेटन को लागू करना
शुरू करने के लिए, हम Java में आधारभूत gRPC सर्वर उपलब्ध कराते हैं, जिसे कंपाइल करके इंस्टॉल किया जा सकता है. इसे देखने के लिए, सैंपल > gRPC रेफ़रंस इंप्लीमेंटेशन सेक्शन में जाएं. इस सर्वर ने ऐसे gRPC तरीकों को अलग कर दिया है जो इंटिग्रेशन में मदद करने के लिए ज़रूरी हैं. इनमें पुष्टि और स्वास्थ्य सेवा भी शामिल है.
ज़रूरी शर्तें
जीआरपीसी गड़बड़ी और बिज़नेस लॉजिक गड़बड़ी
जब कोई पार्टनर बैकएंड, gRPC अनुरोधों को हैंडल करता है, तब दो तरह की गड़बड़ियां हो सकती हैं: गलत डेटा की वजह से अचानक होने वाली गड़बड़ियां; और बिज़नेस लॉजिक से जुड़ी गड़बड़ियां, जो बुकिंग बनाने या उसे अपडेट करने की जानकारी नहीं देती हैं (बुकिंग फ़ेलिंग देखें). उदाहरण के लिए, अगर अनुरोध किया गया स्लॉट उपलब्ध नहीं है.
अचानक कुछ गड़बड़ियां होने पर, उन्हें कैननिकल gRPC गड़बड़ी कोड का इस्तेमाल करके क्लाइंट को लौटाया जाना चाहिए. इसमें ये चीज़ें शामिल हैं लेकिन सिर्फ़ इन तक ही सीमित नहीं हैं:
- INVALID_KEYWORD का इस्तेमाल CheckAvailability और CreateLise जैसे RPC में किया जाता है. अगर दिए गए स्लॉट में अमान्य जानकारी है, तो इन्हें लौटाया जाना चाहिए.
- NOT_FOUND का इस्तेमाल, CreateBooking और ListBookings जैसे RPC में किया जाता है. अगर दिए गए आइडेंटिफ़ायर के बारे में पार्टनर के पास जानकारी नहीं है, तो इसे लौटाया जाना चाहिए.
हर तरीके से जुड़े gRPC गड़बड़ी कोड के बारे में जानकारी देखें या स्थिति कोड की पूरी सूची देखें.
इसके उलट, बिज़नेस लॉजिक से जुड़ी गड़बड़ियों को बुकिंग फ़ेलियर में कैप्चर किया जाना चाहिए और आरपीसी रिस्पॉन्स में दिखाया जाना चाहिए. संसाधन बनाते या अपडेट करते समय कारोबार के लॉजिक से जुड़ी गड़बड़ियां हो सकती हैं. जैसे, RPCs CreateBooking और अपडेट-बुकिंग को मैनेज करते समय. इसमें ये चीज़ें शामिल हैं लेकिन सिर्फ़ इन तक ही सीमित नहीं हैं:
- अगर अनुरोध किया गया स्लॉट अब उपलब्ध नहीं है, तो SLOT_UNAVAILABLE का इस्तेमाल किया जाता है.
- PAYMENT_ERROR_CARD_TYPE_REJECTED का इस्तेमाल तब किया जाता है, जब दिया गया क्रेडिट कार्ड प्रकार स्वीकार नहीं किया जाता है.
पहचान न कर पाना
नेटवर्क पर संचार हमेशा भरोसेमंद नहीं होता है और कोई जवाब न मिलने पर Google Reserve, RPC के लिए फिर से कोशिश कर सकता है. इस वजह से, स्थिति में बदलाव करने वाले सभी RPC (CreateBooking, UpdateBooking) बदलने वाले सही होने चाहिए. इन आरपीसी के अनुरोध में, आइडेम्पटेंसी टोकन शामिल होते हैं, ताकि खास तौर पर अनुरोध की पहचान की जा सके. साथ ही, पार्टनर को दो अलग-अलग बुकिंग और बार-बार किए गए आरपीसी (एक बुकिंग बनाने के इरादे से) के बीच फ़र्क़ करने की अनुमति मिल सके.
इसमें ये चीज़ें शामिल हैं लेकिन सिर्फ़ इन तक ही सीमित नहीं हैं:
- CreateBooking RPC के सफल रिस्पॉन्स में, बनाई गई बुकिंग शामिल होती है और कुछ मामलों में, पेमेंट को बुकिंग फ़्लो के हिस्से के तौर पर प्रोसेस किया जाता है. अगर वही CreateBookingRequest
दूसरी बार मिलता है (इसमें
idempotency_tokenशामिल है), तो वही CreateBookingResponse दिखाना होगा. कोई दूसरी बुकिंग नहीं बनाई जाती और अगर लागू हो, तो उपयोगकर्ता से सिर्फ़ एक बार शुल्क लिया जाता है. ध्यान दें कि अगर CreateBooking की कोशिश नाकाम रहती है, तो वही अनुरोध फिर से भेजने पर, पार्टनर बैकएंड को फिर से कोशिश करनी चाहिए.
आईडी एम्पॉटेंसी के लिए ज़रूरी शर्त, उन सभी तरीकों पर लागू होती है जिनमें आइडेंटी टोकन मौजूद हैं.
gRPC सर्वर की सुरक्षा और पुष्टि
ऐक्शन सेंटर से आपके बैकएंड पर होने वाले कॉल को एसएसएल/TLS का इस्तेमाल करके, सर्टिफ़िकेट पर आधारित म्युचुअल क्लाइंट/सर्वर से पुष्टि करना ज़रूरी है. इसके लिए, आपको gRPC लागू करने के लिए, एक मान्य सर्वर सर्टिफ़िकेट का इस्तेमाल करना होगा. साथ ही, एक मान्य क्लाइंट सर्टिफ़िकेट को स्वीकार करना होगा.
सर्वर सर्टिफ़िकेट: पार्टनर सर्वर के पास, एक मान्य सर्वर सर्टिफ़िकेट होना चाहिए. यह सर्टिफ़िकेट, सर्वर के डोमेन नेम से जुड़ा होना चाहिए (स्वीकार किए गए रूट CA की यह सूची देखें). जीआरपीसी सर्वर इंप्लीमेंटेशन, रूट सर्टिफ़िकेट तक ले जाने वाली सर्टिफ़िकेट चेन की सेवा देता है. इसे पूरा करने का सबसे आसान तरीका यह है कि पार्टनर के वेब होस्ट से मिले इंटरमीडिएट सर्टिफ़िकेट को सर्वर सर्टिफ़िकेट (पीईएम फ़ॉर्मैट में भी) में जोड़कर, उसे PEM फ़ॉर्मैट में जोड़ें.
सर्वर सर्टिफ़िकेट की पुष्टि, कनेक्शन के समय पर की जाती है. साथ ही, खुद हस्ताक्षर किए गए सर्टिफ़िकेट स्वीकार नहीं किए जाते हैं. हालांकि, सर्टिफ़िकेट के मान्य कॉन्टेंट की जांच तब तक नहीं की जाती, जब तक सर्टिफ़िकेट मान्य है. नीचे दिए गए निर्देश का इस्तेमाल करके, अपने सर्टिफ़िकेट की वैधता की जांच की जा सकती है:
echo "" | openssl s_client -connect YOUR_URL:YOUR_PORT -showcerts -CApath /etc/ssl/certs
क्लाइंट सर्टिफ़िकेट: पार्टनर के तौर पर हमारी पुष्टि करने के लिए, हम Google इंटरनेट अथॉरिटी G2 (सीए सर्टिफ़िकेट) से जारी किया गया क्लाइंट सर्टिफ़िकेट देते हैं. इसमें ये प्रॉपर्टी शामिल होती हैं:
| फ़ील्ड | वैल्यू |
|---|---|
CN |
mapsbooking.businesslink-3.net |
SAN |
डीएनएस:mapsbooking.businesslink-3.net |
इस क्लाइंट सर्टिफ़िकेट के बिना कनेक्शन की कोशिशों को पार्टनर सर्वर अस्वीकार कर देना चाहिए.
क्लाइंट सर्टिफ़िकेट की पुष्टि करने के लिए, सर्वर, भरोसेमंद क्लाइंट रूट सर्टिफ़िकेट के सेट पर निर्भर होता है. आपके पास Mozilla जैसी अथॉरिटी से भरोसेमंद रूट का यह सेट पाने का विकल्प होता है. इसके अलावा, Google Internet अथॉरिटी G2 के सुझाए गए रूट का वह सेट भी इंस्टॉल किया जा सकता है. दोनों मामलों में, आपको कभी-कभी रूट सर्टिफ़िकेट को मैन्युअल तरीके से अपडेट करना पड़ सकता है.
जीआरपीसी हेल्थ चेकिंग प्रोटोकॉल को लागू करना
जीआरपीसी हेल्थ चेकिंग
प्रोटोकॉल लागू करें.
इस प्रोटोकॉल की मदद से, Google आपके gRPC लागू करने की बैकएंड स्थिति को मॉनिटर कर सकता है. सेवा की खास जानकारी, जीआरपीसी डिस्ट्रिब्यूशन का हिस्सा है. जीआरपीसी नाम वाले कन्वेंशन के मुताबिक, हेल्थ चेक कॉल में
एपीआई v2 के लिए ext.maps.booking.partner.v2.BookingService या एपीआई v0 के लिए ext.maps.booking.partner.v0.BookingService है. कैंपेन की परफ़ॉर्मेंस की जांच, उसी यूआरएल और पोर्ट पर की जानी चाहिए जिस पर अन्य एंडपॉइंट इस्तेमाल किए जा रहे हैं.
अन्य वर्शन
एपीआई के अन्य वर्शन के दस्तावेज़ देखने के लिए, ये पेज देखें: * एपीआई v3 * एपीआई v0