बुकिंग सर्वर लागू करें: एपीआई v2

अपनी ओर से बुकिंग सर्वर सेट अप करने पर, Actions Center को ये काम करने की अनुमति मिलती है उपयोगकर्ता की ओर से आपके साथ अपॉइंटमेंट / बुकिंग / बुकिंग बनाने के लिए.

gRPC पर आधारित एपीआई इंटरफ़ेस को लागू करना

कृपया ध्यान दें: सभी नए पार्टनर को gRPC के बजाय REST API इंटरफ़ेस का इस्तेमाल करना चाहिए एपीआई.

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

हम अपने नए पार्टनर से, सुझाए गए एपीआई v2 के सेट को लागू करने के लिए कहते हैं. पार्टनर हो सकते हैं उस URL और PORT को चुनें जो उसकी इन्फ़्रास्ट्रक्चर के लिए सर्वश्रेष्ठ काम करता हो.

इस सेक्शन में, एपीआई v2 के सुझाए गए सेट के बारे में बताया गया है. यह उन पार्टनर पर लागू होता है जो API v0 को लागू नहीं किया है. हमारे उन मौजूदा पार्टनर के लिए जिन्होंने एपीआई का इस्तेमाल किया है v0, ज़्यादा जानने के लिए कृपया कार्रवाई केंद्र से संपर्क करें.

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

सेवा को डाउनलोड करें परिभाषा

एपीआई से जुड़े संसाधन

कृपया नीचे दिए गए अलग-अलग तरह के संसाधनों के बारे में जानें. ये संसाधन इस तरीके का इस्तेमाल किया गया है:

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

तरीके

आपके लिए नीचे दिए गए एपीआई तरीकों को लागू करना ज़रूरी है gRPC सर्वर:

इन पांच तरीकों से बुकिंग सेवा आरपीसी के लिए ज़रूरी सेट तय होता है:

// 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 में एक स्केलेटन gRPC सर्वर उपलब्ध कराते हैं जिसे कंपाइल किया जा सकता है और इंस्टॉल किया गया. इसे यहां देखें सैंपल > जीआरपीसी रेफ़रंस को लागू करना सेक्शन में जाएं. इस सर्वर ने gRPC तरीकों का इस्तेमाल नहीं किया है. इसमें पुष्टि करना और स्वास्थ्य सेवा शामिल हैं.

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

gRPC गड़बड़ी और बिज़नेस लॉजिक की गड़बड़ी

जब कोई पार्टनर बैकएंड gRPC अनुरोधों को हैंडल करता है, तब दो तरह की गड़बड़ियां हो सकती हैं: गलत डेटा की वजह से अचानक से कोई गड़बड़ी होना; और कारोबारी लॉजिक से जुड़ी गड़बड़ियां होती हैं, जो बुकिंग करने या अपडेट करने में दिक्कत आ रही है (बुकिंग देखें विफलता), उदाहरण के लिए, अनुरोध किया गया स्लॉट उपलब्ध न होने पर.

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

  • INVALID_उपयोगकर्ताओं का इस्तेमाल RPC में किया जाता है, जैसे कि CheckAvailability और CreateLease, और अगर दिए गए स्लॉट में अमान्य जानकारी है, तो उसे लौटाया जाना चाहिए.
  • NOT_FOUND का इस्तेमाल RPC में किया जाता है. जैसे, CreateBooking और ListBookings. इसके लिए यह ज़रूरी है अगर दिया गया आइडेंटिफ़ायर पार्टनर के पास नहीं है, तो उसे लौटाया जा सकता है.

हर तरीके के कैननिकल gRPC गड़बड़ी कोड का संदर्भ देखें या पूरा स्टेटस कोड की सूची.

इसके उलट, बिज़नेस लॉजिक की गड़बड़ियों को बुकिंग में कैप्चर किया जाना चाहिए गड़बड़ी हुई और RPC जवाब में लौटाया गया. रिपोर्ट बनाते समय, बिज़नेस लॉजिक से जुड़ी गड़बड़ियां हो सकती हैं या किसी संसाधन को अपडेट करना. जैसे, RPC CreateBooking को मैनेज करना, और अपडेट बुकिंग. इसमें ये चीज़ें शामिल हैं लेकिन सिर्फ़ इन तक ही सीमित नहीं हैं:

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

इडेमपोटेंसी

नेटवर्क पर बातचीत हमेशा भरोसेमंद नहीं होती और Google Reserve शायद कोई जवाब न मिलने पर RPC फिर से आज़माएं. इस कारण से, बदलाव करने वाले सभी RPC स्थिति (CreateBooking, UpdateBooking) तय होनी चाहिए. इसके लिए मैसेज का अनुरोध करें इन आरपीसी में, अनुरोध की खास पहचान करने और अनुमति देने के लिए ज़रूरी जानकारी देने वाले टोकन शामिल होते हैं ताकि पुनर्प्रयास की गई RPC (जिसका उद्देश्य एक बुकिंग) और दो अलग-अलग बुकिंग

इसमें ये चीज़ें शामिल हैं लेकिन सिर्फ़ इन तक ही सीमित नहीं हैं:

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

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

gRPC सर्वर सुरक्षा और प्रमाणीकरण

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

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

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

echo "" | openssl s_client  -connect YOUR_URL:YOUR_PORT  -showcerts -CApath /etc/ssl/certs

क्लाइंट सर्टिफ़िकेट: पार्टनर के तौर पर हमारी पुष्टि करने के लिए, हम Google इंटरनेट अथॉरिटी G2 (CA) से जारी किया गया क्लाइंट सर्टिफ़िकेट देते हैं सर्टिफ़िकेट के साथ ये प्रॉपर्टी:

फ़ील्ड मान
CN mapsbooking.businesslink-3.net
SAN डीएनएस:mapsbooking.businesslink-3.net

इस क्लाइंट सर्टिफ़िकेट के बिना कनेक्शन की कोशिशों को, पार्टनर सर्वर पर क्लिक करें.

क्लाइंट सर्टिफ़िकेट की पुष्टि करने के लिए, सर्वर भरोसेमंद क्लाइंट के सेट का इस्तेमाल करता है रूट सर्टिफ़िकेट. भरोसेमंद रूट के इस सेट को किसी Mozilla जैसे अधिकार या Google इंटरनेट द्वारा वर्तमान में सुझाए गए जड़ों का सेट इंस्टॉल करें अथॉरिटी G2. दोनों में ऐसी स्थिति में, आपको कभी-कभी रूट सर्टिफ़िकेट को मैन्युअल तरीके से अपडेट करना पड़ सकता है.

gRPC हेल्थ चेकिंग प्रोटोकॉल लागू करें

GRPC हेल्थ चेकिंग लागू करें प्रोटोकॉल. इस प्रोटोकॉल की मदद से, Google आपके gRPC के बैकएंड स्टेटस को मॉनिटर कर पाता है लागू करना. सेवा खास जानकारी GRPC डिस्ट्रिब्यूशन का हिस्सा है. जीआरपीसी नाम देने की परंपरा के हिसाब से, स्वास्थ्य की जांच के लिए कॉल में मौजूद सेवा एपीआई v2 के लिए ext.maps.booking.partner.v2.BookingService या एपीआई v0 के लिए ext.maps.booking.partner.v0.BookingService. स्वास्थ्य जाँच को दूसरे एंडपॉइंट की तरह ही उसी यूआरएल और PORT पर चलाएं.

अन्य वर्शन

API के अन्य वर्शन के दस्तावेज़ देखने के लिए, ये पेज देखें: * एपीआई v3 * एपीआई v0