अपने सिस्टम पर बुकिंग सर्वर सेट अप करने से, Actions Center को उपयोगकर्ता की ओर से आपके साथ अपॉइंटमेंट / बुकिंग / आरक्षण करने की अनुमति मिलेगी.
gRPC पर आधारित एपीआई इंटरफ़ेस लागू करना
कृपया ध्यान दें: सभी नए पार्टनर को gRPC API के बजाय REST API इंटरफ़ेस का इस्तेमाल करना चाहिए.
gRPC पर आधारित एपीआई इंटरफ़ेस लागू करें. इससे Google को बुकिंग के अनुरोध भेजने की अनुमति मिलती है. एपीआई सरफेस को gRPC के प्रोटोबफ़ आधारित आईडीएल का इस्तेमाल करके तय किया जाता है.
हम अपने नए पार्टनर से, एपीआई v2 का सुझाया गया सेट लागू करने के लिए कहते हैं. पार्टनर, अपने इन्फ़्रास्ट्रक्चर के हिसाब से कोई भी यूआरएल और पोर्ट चुन सकते हैं.
इस सेक्शन में, एपीआई v2 के सुझाए गए सेट के बारे में बताया गया है. यह उन पार्टनर पर लागू होता है जिन्होंने एपीआई v0 लागू नहीं किया है. जिन मौजूदा पार्टनर ने API v0 लागू किया है वे ज़्यादा जानने के लिए, कृपया Actions Center से संपर्क करें.
एपीआई लागू करने के लिए, यहां दिया गया सेवा का डेफ़िनिशन proto फ़ॉर्मैट में डाउनलोड करें.
एपीआई रिसॉर्स
कृपया यहां दिए गए संसाधन टाइप के बारे में जानें. इनका इस्तेमाल इस सुविधा को लागू करने के लिए किया जाएगा:
तरीके
gRPC सर्वर के लिए, आपको यहां दिए गए एपीआई तरीके लागू करने होंगे:
इन पांच तरीकों से, BookingService RPC के ज़रूरी सेट के बारे में पता चलता है:
// 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 पार्टनर को उपयोगकर्ता का नाम, उपनाम, फ़ोन नंबर, और ईमेल पता भेजेगा. पार्टनर के हिसाब से, इसे मेहमान के तौर पर चेकआउट करने की सुविधा के तौर पर माना जाना चाहिए. ऐसा इसलिए, क्योंकि Actions Center के पास पार्टनर के सिस्टम में उपयोगकर्ता का खाता ढूंढने का कोई तरीका नहीं है. पार्टनर के कारोबारियों या कंपनियों को, उनके सिस्टम में फ़ाइनल बुकिंग दिखनी चाहिए. यह बुकिंग, पार्टनर के बुकिंग सिस्टम से आने वाली बुकिंग की तरह ही दिखनी चाहिए.
Java में कंकाल को लागू करना
शुरू करने के लिए, हम Java में एक स्केलेटन gRPC सर्वर उपलब्ध कराते हैं. इसे कंपाइल और इंस्टॉल किया जा सकता है. इसे सैंपल > gRPC का रेफ़रंस इंप्लीमेंटेशन सेक्शन में जाकर देखें. इस सर्वर में, gRPC के ऐसे तरीके शामिल हैं जिनकी ज़रूरत इंटिग्रेशन के लिए होती है. इनमें पुष्टि करने और स्वास्थ्य सेवा से जुड़े तरीके शामिल हैं.
ज़रूरी शर्तें
gRPC गड़बड़ी और कारोबार के लॉजिक से जुड़ी गड़बड़ी
gRPC अनुरोधों को मैनेज करते समय, पार्टनर के बैकएंड में दो तरह की गड़बड़ियां हो सकती हैं: गलत डेटा की वजह से होने वाली गड़बड़ियां; और कारोबार के लॉजिक से जुड़ी गड़बड़ियां.ये गड़बड़ियां, बुकिंग बनाने या अपडेट करने में समस्या होने की वजह से होती हैं (बुकिंग नहीं हो पाई देखें). उदाहरण के लिए, अगर अनुरोध किया गया स्लॉट उपलब्ध नहीं है.
अगर कोई ऐसी गड़बड़ी होती है जिसकी उम्मीद नहीं थी, तो उसे क्लाइंट को वापस भेज देना चाहिए. इसके लिए, कैननिकल gRPC गड़बड़ी कोड का इस्तेमाल करें. इसमें ये चीज़ें शामिल हैं लेकिन सिर्फ़ इन तक ही सीमित नहीं हैं:
- INVALID_ARGUMENT का इस्तेमाल CheckAvailability और CreateLease जैसे आरपीसी में किया जाता है. अगर दिए गए स्लॉट में अमान्य जानकारी मौजूद है, तो इसे वापस कर दिया जाना चाहिए.
- NOT_FOUND का इस्तेमाल CreateBooking और ListBookings जैसे आरपीसी में किया जाता है. अगर पार्टनर को दिए गए आइडेंटिफ़ायर के बारे में जानकारी नहीं है, तो इसे वापस कर दिया जाना चाहिए.
हर तरीके के कैननिकल gRPC गड़बड़ी कोड का रेफ़रंस देखें या स्टेटस कोड की पूरी लिस्ट देखें.
इसके उलट, कारोबार के लॉजिक से जुड़ी गड़बड़ियों को Booking Failure में कैप्चर किया जाना चाहिए. साथ ही, RPC रिस्पॉन्स में इसकी जानकारी दी जानी चाहिए. कारोबार के लॉजिक से जुड़ी गड़बड़ियां, संसाधन बनाते या अपडेट करते समय हो सकती हैं. जैसे, CreateBooking और UpdatingBooking आरपीसी को हैंडल करते समय. इसमें ये चीज़ें शामिल हैं लेकिन सिर्फ़ इन तक ही सीमित नहीं हैं:
- अगर अनुरोध किया गया स्लॉट अब उपलब्ध नहीं है, तो SLOT_UNAVAILABLE का इस्तेमाल किया जाता है.
- अगर दिए गए क्रेडिट कार्ड का टाइप स्वीकार नहीं किया जाता है, तो PAYMENT_ERROR_CARD_TYPE_REJECTED का इस्तेमाल किया जाता है.
आइडमपोटेंसी
नेटवर्क पर कम्यूनिकेशन हमेशा भरोसेमंद नहीं होता. अगर कोई जवाब नहीं मिलता है, तो Google Reserve, आरपीसी को फिर से आज़मा सकता है. इस वजह से, स्थिति में बदलाव करने वाली सभी आरपीसी (CreateBooking, UpdateBooking) को आइडमपोटेंट होना चाहिए. इन आरपीसी के लिए अनुरोध वाले मैसेज में, आइडमपोटेंसी टोकन शामिल होते हैं. इनसे अनुरोध की पहचान की जाती है. साथ ही, पार्टनर को यह पता चलता है कि आरपीसी को फिर से आज़माया गया है (एक बुकिंग बनाने के मकसद से) या दो अलग-अलग बुकिंग की गई हैं.
इसमें ये चीज़ें शामिल हैं लेकिन सिर्फ़ इन तक ही सीमित नहीं हैं:
- CreateBooking आरपीसी के जवाब में, बनाई गई बुकिंग की जानकारी शामिल होती है. साथ ही, कुछ मामलों में बुकिंग फ़्लो के दौरान पेमेंट प्रोसेस किया जाता है. अगर CreateBookingRequest को दूसरी बार (
idempotency_tokenको शामिल करके) भेजा जाता है, तो CreateBookingResponse को वापस भेजना होगा. कोई दूसरी बुकिंग नहीं बनाई जाती है. साथ ही, अगर उपयोगकर्ता पर लागू होता है, तो उससे सिर्फ़ एक बार शुल्क लिया जाता है. ध्यान दें कि अगर CreateBooking का अनुरोध पूरा नहीं होता है, तो पार्टनर के बैकएंड को फिर से कोशिश करनी चाहिए. ऐसा तब करना चाहिए, जब उसी अनुरोध को फिर से भेजा गया हो.
आईडंपोटेंसी की ज़रूरी शर्त, उन सभी तरीकों पर लागू होती है जिनमें आईडंपोटेंसी टोकन शामिल होते हैं.
gRPC सर्वर की सुरक्षा और पुष्टि करना
ऐक्शन सेंटर से आपके बैकएंड पर किए जाने वाले कॉल को एसएसएल/टीएलएस का इस्तेमाल करके सुरक्षित किया जाना चाहिए. साथ ही, क्लाइंट/सर्वर के आपसी ऑथेंटिकेशन के लिए, सर्टिफ़िकेट का इस्तेमाल किया जाना चाहिए. इसके लिए, आपको gRPC लागू करने के लिए मान्य सर्वर सर्टिफ़िकेट का इस्तेमाल करना होगा. साथ ही, मान्य क्लाइंट सर्टिफ़िकेट स्वीकार करना होगा.
सर्वर सर्टिफ़िकेट: पार्टनर सर्वर के पास, सर्वर के डोमेन नेम से जुड़ा मान्य सर्वर सर्टिफ़िकेट होना चाहिए. स्वीकार किए गए रूट CA की इस सूची को देखें. GRPC सर्वर को लागू करने के लिए, एक ऐसी सर्टिफ़िकेट चेन की ज़रूरत होती है जो रूट सर्टिफ़िकेट तक जाती हो. इसे पूरा करने का सबसे आसान तरीका यह है कि पार्टनर की वेब होस्टिंग कंपनी से मिले इंटरमीडिएट सर्टिफ़िकेट को पीईएम फ़ॉर्मैट में सर्वर सर्टिफ़िकेट (यह भी पीईएम फ़ॉर्मैट में होना चाहिए) में जोड़ दिया जाए.
कनेक्शन के समय सर्वर सर्टिफ़िकेट की पुष्टि की जाती है. साथ ही, खुद से हस्ताक्षर किए गए सर्टिफ़िकेट स्वीकार नहीं किए जाते. जब तक सर्टिफ़िकेट मान्य है, तब तक उसके कॉन्टेंट की जांच नहीं की जाती. इस कमांड का इस्तेमाल करके, अपने सर्टिफ़िकेट की वैधता की जांच की जा सकती है:
echo "" | openssl s_client -connect YOUR_URL:YOUR_PORT -showcerts -CApath /etc/ssl/certs
क्लाइंट सर्टिफ़िकेट: पार्टनर को हमारी (Google के तौर पर) पुष्टि करने के लिए, हम Google Internet Authority G2 (CA सर्टिफ़िकेट) से जारी किया गया क्लाइंट सर्टिफ़िकेट देते हैं. इसमें ये प्रॉपर्टी होती हैं:
| फ़ील्ड | मान |
|---|---|
CN |
mapsbooking.businesslink-3.net |
SAN |
DNS:mapsbooking.businesslink-3.net |
इस क्लाइंट सर्टिफ़िकेट के बिना कनेक्शन बनाने की कोशिशों को पार्टनर सर्वर को अस्वीकार करना चाहिए.
क्लाइंट सर्टिफ़िकेट की पुष्टि करने के लिए, सर्वर भरोसेमंद क्लाइंट रूट सर्टिफ़िकेट के सेट पर निर्भर करता है. आपके पास Mozilla जैसी किसी संस्था से, भरोसेमंद रूट का यह सेट पाने का विकल्प होता है. इसके अलावा, Google Internet Authority G2 की ओर से फ़िलहाल सुझाए गए रूट का सेट भी इंस्टॉल किया जा सकता है. इन दोनों ही मामलों में, आपको कभी-कभी रूट सर्टिफ़िकेट को मैन्युअल तरीके से अपडेट करना पड़ सकता है.
gRPC Health Checking Protocol लागू करना
GRPC Health Checking Protocol लागू करें.
इस प्रोटोकॉल की मदद से, Google आपके gRPC लागू करने के बैकएंड स्टेटस को मॉनिटर कर पाता है. सेवा की खास जानकारी, GRPC डिस्ट्रिब्यूशन का हिस्सा है. GRPC के नाम रखने के तरीके के मुताबिक, हेल्थ चेक कॉल में सेवा का नाम ext.maps.booking.partner.v2.BookingService एपीआई v2 के लिए या ext.maps.booking.partner.v0.BookingService एपीआई v0 के लिए है. परफ़ॉर्मेंस की जांच, उसी यूआरएल और पोर्ट पर होनी चाहिए जिस पर अन्य एंडपॉइंट होते हैं.
अन्य वर्शन
एपीआई के अन्य वर्शन के दस्तावेज़ के लिए, ये पेज देखें: * एपीआई v3 * एपीआई v0