बुकिंग सर्वर लागू करना: एपीआई वर्शन 2

अपने यहां बुकिंग सर्वर सेट अप करने पर, ऐक्शन सेंटर आपके साथ उपयोगकर्ता की ओर से अपॉइंटमेंट / बुकिंग / रिज़र्वेशन बना सकेगा.

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

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

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

हम अपने नए पार्टनर से, एपीआई v2 के सुझाए गए सेट को लागू करने के लिए कहते हैं. पार्टनर, अपने इन्फ़्रास्ट्रक्चर के लिए सबसे सही यूआरएल और पोर्ट चुन सकते हैं.

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

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

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

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

कृपया यहां दिए गए संसाधनों के बारे में जानें. इन्हें इस सुविधा को लागू करने के लिए इस्तेमाल किया जाएगा:

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

तरीके

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 पार्टनर को उपयोगकर्ता का नाम, उपनाम, फ़ोन नंबर, और ईमेल भेजेगा. पार्टनर के हिसाब से, इसे मेहमान के तौर पर चेकआउट के तौर पर माना जाना चाहिए. ऐसा इसलिए, क्योंकि Actions Center में पार्टनर के सिस्टम में उपयोगकर्ता के खाते को देखने का कोई तरीका नहीं है. फ़ाइनल बुकिंग, पार्टनर के व्यापारियों/कंपनियों/कारोबारियों को उनके सिस्टम में दिखनी चाहिए. ठीक उसी तरह जैसे पार्टनर के बुकिंग सिस्टम में बुकिंग दिखती हैं.

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

शुरू करने के लिए, हम Java में एक स्केलेटन gRPC सर्वर उपलब्ध कराते हैं, जिसे कंपाइल और इंस्टॉल किया जा सकता है. इसे सैंपल > gRPC रेफ़रंस लागू करना सेक्शन में देखें. इस सर्वर में, पुष्टि करने और हेल्थ सेवा के साथ-साथ इंटिग्रेशन के लिए ज़रूरी gRPC तरीके स्टब किए गए हैं.

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

gRPC गड़बड़ी और कारोबार के लॉजिक से जुड़ी गड़बड़ी

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

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

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

हर तरीके के लिए, कैननिकल 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 लागू करने के लिए मान्य सर्वर सर्टिफ़िकेट का इस्तेमाल करना और मान्य क्लाइंट सर्टिफ़िकेट स्वीकार करना ज़रूरी है.

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

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

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

क्लाइंट सर्टिफ़िकेट: पार्टनर को Google के तौर पर हमारी पुष्टि करने के लिए, हम Google Internet Authority G2 (सीए सर्टिफ़िकेट) से जारी किया गया क्लाइंट सर्टिफ़िकेट उपलब्ध कराते हैं. इसमें ये प्रॉपर्टी शामिल होती हैं:

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

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

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

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

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

अन्य वर्शन

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