पार्टनर सर्वर

किराये और उपलब्धता की जानकारी को इंटिग्रेट करने के लिए, पार्टनर को Partner API लागू करना होगा. यह इंटरफ़ेस REST पर आधारित है. इसकी मदद से Google, HTTP पर लाइव कॉल भेज सकता है. रेफ़रंस सेक्शन में, अलग-अलग एपीआई तरीकों के बारे में जानकारी दी गई है. हालांकि, आपको बाद में क्रॉसकटिंग से जुड़ी समस्याओं के बारे में जानकारी मिल सकती है.

अनुरोध और जवाब का फ़ॉर्मैट

शुरुआत में, सिर्फ़ JSON फ़ॉर्मैट इस्तेमाल किए जा सकेंगे. अगर आपको अनुरोध या जवाब के अन्य फ़ॉर्मैट चाहिए, तो Travel Transport टीम से संपर्क करें. इसके लिए, transport-help@google.com पर ईमेल भेजें. इसमें अपने इस्तेमाल के उदाहरण के बारे में बताएं.

अनुरोध, एचटीटीपी पोस्ट मेथड का इस्तेमाल करके भेजे जाएंगे. साथ ही, अनुरोध का मैसेज, पोस्ट बॉडी में होगा.

ध्यान दें कि स्ट्रक्चर को साफ़ तौर पर समझने के लिए, एपीआई इंटरफ़ेस के दस्तावेज़ को प्रोटोकॉल बफ़र मैसेज की परिभाषाओं के तौर पर दिया गया है. साथ ही, प्रोटोकॉल बफ़र मैसेज की परिभाषा को JSON ऑब्जेक्ट में बदलने की प्रोसेस को कैननिकल JSON मैपिंग के तौर पर तय किया गया है. इसमें डिफ़ॉल्ट वैल्यू वाले फ़ील्ड दिखाने और lowerCamelCase नामों के बजाय प्रोटो फ़ील्ड के नामों का इस्तेमाल करने के लिए, options का इस्तेमाल किया जाता है.

पुष्टि करना

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

स्टेटस कोड और गड़बड़ी को ठीक करना

आम तौर पर, एचटीटीपी रिस्पॉन्स में ये स्टेटस कोड दिखाए जा सकते हैं:

एचटीटीपी कोड एचटीटीपी के बारे में जानकारी नोट
2xx ठीक यह कोई गड़बड़ी नहीं है. यह अनुरोध पूरा होने पर दिखता है. जवाब के मुख्य हिस्से में, नतीजे के तौर पर TripOptionsResult जैसा कोई ऑब्जेक्ट होना चाहिए. इसमें गड़बड़ी का जवाब नहीं होना चाहिए.
400 गलत अनुरोध हमें मिला अनुरोध अमान्य था. जवाब के मुख्य हिस्से में गड़बड़ी के बारे में ज़्यादा जानकारी देने के लिए, तरीके के हिसाब से गड़बड़ी के जवाबों का इस्तेमाल किया जाना चाहिए. एचटीटीपी 400 का इस्तेमाल आम तौर पर सिर्फ़ तब किया जाना चाहिए, जब Google से कोई तकनीकी गड़बड़ी हुई हो. जैसे, अनुरोध में किसी फ़ील्ड का नाम गलत हो.
403 अनुमति नहीं है अनुमति नहीं दी गई/मना किया गया (कॉल करने वाले की पहचान हो गई है और उसे अस्वीकार कर दिया गया है). इस जवाब का इस्तेमाल, किसी संसाधन के खत्म होने की वजह से अनुरोध अस्वीकार होने पर नहीं किया जाना चाहिए. इसके बजाय, उन गड़बड़ियों के लिए 'बहुत ज़्यादा अनुरोध' का इस्तेमाल करें. अगर कॉल करने वाले की पहचान नहीं की जा सकती, तो Forbidden का इस्तेमाल नहीं किया जाना चाहिए. इसके बजाय, उन गड़बड़ियों के लिए Unauthorized का इस्तेमाल करें.
404 नहीं मिला अनुरोध किया गया संसाधन नहीं मिला. जवाब के मुख्य हिस्से में गड़बड़ी के बारे में ज़्यादा जानकारी देने के लिए, तरीके के हिसाब से गड़बड़ी के जवाबों का इस्तेमाल किया जाना चाहिए.
429 अत्‍यधिक अनुरोध कुछ संसाधन खत्म हो गए हैं. ऐसा हो सकता है कि हर उपयोगकर्ता के लिए तय किया गया कोटा खत्म हो गया हो.
500 आंतरिक सर्वर गड़बड़ी सिस्टम की गड़बड़ियां. इसका मतलब है कि सिस्टम को जिन इनवेरिएंट की ज़रूरत होती है उनमें से कुछ टूट गए हैं. गड़बड़ी का यह कोड, गंभीर गड़बड़ियों के लिए रिज़र्व किया गया है. इससे पता चलता है कि पार्टनर के एपीआई सर्वर को लागू करने में कोई गड़बड़ी हुई है.
503 सेवा उपलब्ध नहीं है यह सेवा उपलब्ध नहीं है. यह एक अस्थायी समस्या है. कुछ समय बाद फिर से कोशिश करने पर, यह ठीक हो सकती है.
504 गेटवे का टाइम आउट हो गया कार्रवाई पूरी होने से पहले ही समयसीमा खत्म हो गई. सिस्टम की स्थिति में बदलाव करने वाली कार्रवाइयों के लिए, यह गड़बड़ी तब भी दिख सकती है, जब कार्रवाई पूरी हो गई हो. उदाहरण के लिए, किसी सर्वर से मिला जवाब, समयसीमा खत्म होने के बाद मिला हो.

ध्यान दें कि सभी पूर्व शर्तों, अमान्य तर्कों या नहीं मिली गड़बड़ियों के लिए:

  • एपीआई में तय किए गए, तरीके के हिसाब से जवाब या गड़बड़ी के मैसेज इस्तेमाल किए जाने चाहिए.
  • सही एचटीटीपी कोड का इस्तेमाल किया जाना चाहिए. यह कोड, तरीके के हिसाब से तय किए गए कोड में दिया गया है (उदाहरण के लिए, TripOptionsErrorType देखें)

इससे इन तरह की गड़बड़ियों के बारे में ज़्यादा जानकारी दी जा सकती है. इस जानकारी का इस्तेमाल इन कामों के लिए किया जा सकता है:

  • यह तय करना कि क्या किसी गड़बड़ी को फिर से ठीक किया जा सकता है
    • SEGMENT_KEY_NOT_FOUND को फिर से आज़माया नहीं जा सकता.
  • पुरानी जानकारी को सही करें
    • Unavailable.Reason.CANCELED से पता चलता है कि यात्रा को हटा दिया गया है (ध्यान दें कि यह एक सफल जवाब का हिस्सा है)
    • Unavailable.Reason.TEMPORARILY_UNAVAILABLE के साथ-साथ गड़बड़ी के कोड SEGMENT_KEY_NOT_FOUND, SUBOPTIMAL_ITINERARY, BOOKING_WINDOW_NOT_SUPPORTED, और TICKETING_PROHIBITED, कैश मेमोरी से मिले सभी किराये हटा देते हैं.
  • उपयोगकर्ताओं को काम की सलाह देना

तरीके के हिसाब से गड़बड़ियों की मौजूदा सूची, TripOptionsError में दी गई है. यह सूची, शुरुआती जानकारी के तौर पर दी गई है. अगर आपको अन्य तरह की गड़बड़ियों के बारे में जानना है, तो कृपया Google Travel Transport टीम से संपर्क करें.

क्यूपीएस (क्वेरी प्रति सेकंड)

Google की ओर से भेजे गए QPS का लेवल, पार्टनर की इन्वेंट्री और इस बात पर निर्भर करता है कि कितने उपयोगकर्ता, कैश मेमोरी में सेव किए गए डेटा को देखते हैं या बुकिंग के लिए पार्टनर की वेबसाइटों पर क्लिक करते हैं.

इंतज़ार का समय

अनुरोधों की समयसीमा 10 सेकंड के बाद खत्म हो जाएगी. बीटा पार्टनर इंटिग्रेशन के लिए, लेटेन्सी से जुड़ी कोई अतिरिक्त गाइडलाइन नहीं होगी. हालांकि, लेटेन्सी के अन्य एसएलओ, पार्टनर के लिए डेटा क्वालिटी के दिशा-निर्देशों में तय किए जाएंगे.

मुद्राएं, टैक्स, और शुल्क

Google को भेजी गई सभी कीमतों में सभी टैक्स और शुल्क शामिल होने चाहिए. साथ ही, ये कीमतें, इस्तेमाल की जा सकने वाली मुद्रा में बताई जानी चाहिए.

मुद्रा

कीमत के लिए मुद्रा, currency_code फ़ील्ड का इस्तेमाल करके तय की जाती है. यह ISO 4217 के मुताबिक मान्य मुद्रा कोड होना चाहिए.

उदाहरण 10.25 USD:

{
  "price": {
    "currency_code": "USD",
    "units": 10,
    "nanos": 250000000
  }
}

टैक्स और शुल्क

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