प्रोटोकॉल के स्टैंडर्ड

एपीआई, एचटीटीपी एपीआई स्टैंडर्ड के एक सेट का पालन करता है और काम करता है नज़रबंदी की भावना ताकि ज़्यादा बेहतर नतीजे मिल सकें इंटिग्रेशन.

Google की ओर से होस्ट किए गए यूआरएल

Google के होस्ट किए गए हर तरीके के दस्तावेज़ में एक बेस यूआरएल होता है, जो इसमें मेथड का नाम और मेजर वर्शन नंबर शामिल होता है. पूरा यूआरएल बनाया गया कॉलर के पेमेंट इंटिग्रेटर खाता आईडी को खत्म. उदाहरण के लिए, Google के होस्ट किए गए इको तरीके से जुड़ा दस्तावेज़ यूआरएल को बताता है:

https://vgw.googleapis.com/secure-serving/gsp/v1/echo

अगर कॉल करने वाले (कॉलर) का पेमेंट इंटिग्रेटर खाता आईडी INTEGRATOR_1 है, तो वह जो कि यूआरएल के आखिर तक बनेगा:

https://vgw.googleapis.com/secure-serving/gsp/v1/echo/INTEGRATOR_1

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

पार्टनर के होस्ट किए गए यूआरएल

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

सैंडबॉक्स और प्रोडक्शन एनवायरमेंट

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

Google उम्मीद करता है कि आपका सैंडबॉक्स हमेशा उपलब्ध रहेगा, क्योंकि सैंडबॉक्स का इस्तेमाल किया जा सकता है.

Google का सैंडबॉक्स बेस पाथ

https://vgw.sandbox.google.com/secure-serving/gsp/

ध्यान दें: अगर आपका इंटिग्रेशन पहले ही लॉन्च किया जा चुका है और https://billpaynotification.sandbox.googleapis.com होस्ट, आप जारी रख सकते हैं शामिल हैं. नए इंटिग्रेशन को 'vgw.sandbox.google.com' कॉल करना चाहिए होस्ट.

Google का प्रोडक्शन बेस पाथ

https://vgw.googleapis.com/secure-serving/gsp/

ध्यान दें: अगर आपका इंटिग्रेशन पहले ही लॉन्च किया जा चुका है और https://billpaynotification.googleapis.com होस्ट, आप आगे भी ऐसा कर सकते हैं. नए इंटिग्रेशन को 'vgw.googleapis.com' पर कॉल करना चाहिए होस्ट.

यह गाइड, प्रोडक्शन एंडपॉइंट का इस्तेमाल करेगी.

कॉन्टेंट का टाइप और एन्कोडिंग

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है मैसेज पेलोड जो PGP एन्क्रिप्शन का इस्तेमाल करते हैं उन्हें सामग्री प्रकार का इस्तेमाल करना होगा application/octet-stream; charset=utf-8. PGP से जुड़े अनुरोध के निकायों में यह ज़रूरी है कि base64url एन्कोडिंग का उपयोग करके भेजा जाएगा, जैसा कि rfc4648 §5. अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है जिन मैसेज पेलोड में JWE एन्क्रिप्शन का इस्तेमाल किया गया है उन्हें कॉन्टेंट टाइप का इस्तेमाल करना होगा application/jose; charset=utf-8. कॉम्पैक्ट सीरियलाइज़ेशन का विकल्प JWE/JWS द्वारा समर्थित, अंतिम अनुरोध के मुख्य भाग के लिए एन्कोडिंग को हैंडल करते हैं.

एचटीटीपी स्टेटस कोड

स्टैंडर्ड पेमेंट्स एपीआई को, एचटीटीपी 200 स्टेटस कोड दिखाने के लिए डिज़ाइन किया गया है उन सभी अनुरोधों के लिए जिन्हें सर्वर प्रोसेस कर सकता है. इसमें ये दोनों चीज़ें शामिल हैं कारोबार के लिहाज़ से सही अनुरोध मिले हों और उन्हें अस्वीकार कर दिया गया हो या ऐप्लिकेशन लॉजिक के हिसाब से होना चाहिए. जिन अनुरोधों को प्रोसेस नहीं किया जा सकता उनका नतीजा यह नहीं होना चाहिए कि एचटीटीपी 200 स्थिति कोड, क्योंकि वे Google और पार्टनर के साथ शेयर करें. इसके बजाय, एपीआई से मिले रिस्पॉन्स में सही एचटीटीपी स्टेटस का इस्तेमाल किया जाना चाहिए वैकल्पिक ErrorResponse ऑब्जेक्ट के साथ नीचे दिए गए कोड.

एचटीटीपी गड़बड़ियां और वजहें
400	BAD REQUEST क्लाइंट ने कोई अमान्य तर्क डाला है. इसे तब भी लौटाया जा सकता है, जब सिस्टम की वजह से कार्रवाई को अस्वीकार कर दिया गया हो कार्रवाई के निष्पादन के लिए आवश्यक स्थिति में नहीं है. इसका इस्तेमाल तब करें, जब सिस्टम की स्थिति से पहले अनुरोध को बार-बार करने की कोशिश न की जा सके को साफ़ तौर पर ठीक कर दिया गया है. उदाहरण के लिए, अगर किसी वजह से रिफ़ंड का अनुरोध पूरा नहीं होता यह किसी ऐसे कैप्चर का रेफ़रंस देता है जो मौजूद नहीं है, फिर से करने की कोशिश सफल नहीं होगी जब तक कि इंटीग्रेटर सिस्टम में कैप्चर मौजूद न हो. ध्यान दें: BAD_REQUEST (400) का इस्तेमाल नहीं किया जाना चाहिए उन स्थितियों में लागू किया जा सकता है, जिनमें ऐप्लिकेशन में कोई गड़बड़ी हुई हो. इसके लिए उदाहरण के लिए, गलत मुद्राएं दिखाई जानी चाहिए कोड 200 का इस्तेमाल करके ACCOUNT_DOES_NOT_SUPPORT_CURRENCY, अगर स्टैंडर्ड रिस्पॉन्स में वह फ़ील्ड या enum होता है.
401	UNAUTHORIZED अनुरोध में इसके लिए मान्य प्रमाणीकरण क्रेडेंशियल नहीं हैं कार्रवाई. उदाहरण के लिए, अमान्य हस्ताक्षर या अज्ञात हस्ताक्षर के लिए यह ज़रूरी है रिटर्न 401 है.
403	FORBIDDEN / PERMISSION DENIED कॉलर को तय कार्रवाई करने की अनुमति नहीं है.
404	NOT FOUND पेमेंट या उपयोगकर्ता जैसी कुछ अनुरोध की गई इकाई नहीं मिली.
409	CONFLICT / ABORTED आम तौर पर, एक साथ कई गड़बड़ियां होने की वजह से, ऑपरेशन रद्द कर दिया जाता था. जैसे, सीक्वेंसर-चेक फ़ेल्स, ट्रांज़ैक्शन रद्द होना वगैरह.
412	PRECONDITION FAILED इस कोड का इस्तेमाल उन स्थितियों में किया जाना चाहिए जब एक आइडिम्पोटेंसी कुंजी का इस्तेमाल किया जा रहा हो पैरामीटर का इस्तेमाल किया जाता है.
429	RESOURCE EXHAUSTED / TOO MANY REQUESTS सिस्टम के कुछ संसाधन खत्म हो गए हैं.
499	CANCELLED कार्रवाई रद्द की गई (आम तौर पर कॉलर की ओर से).
500	INTERNAL ERROR अंदरूनी गड़बड़ियां. इसका मतलब है कि मौजूदा सिस्टम से कुछ इनवैरिएंट की उम्मीद है टूट गया है.
501	UNIMPLEMENTED इस सेवा में ऑपरेशन लागू, समर्थित या सक्षम नहीं किया गया है.
503	UNAVAILABLE फ़िलहाल, सेवा उपलब्ध नहीं है. यह कुछ समय के लिए स्थिति सही है और फिर से कोशिश करके इसे ठीक किया जा सकता है.
504	GATEWAY TIMEOUT / DEADLINE EXCEEDED कार्रवाई पूरी होने से पहले, समयसीमा खत्म हो गई. ऐसी कार्रवाइयों के लिए सिस्टम की स्थिति बदल देते हैं, तो यह गड़बड़ी वापस मिल सकती है, भले ही कार्रवाई सफलतापूर्वक पूरी हो गई. उदाहरण के लिए, एक अच्छा जवाब सर्वर से होने वाली देरी से की समयसीमा खत्म होने वाली है.

विचार-विमर्श का अनुरोध करें

अनुरोध की स्थिति, स्टैंडर्ड पेमेंट में इस्तेमाल की जाने वाली मुख्य रणनीति है ऐसे एपीआई जिनका इस्तेमाल यह पक्का करने के लिए किया जाता है कि Google और पार्टनर के बीच सिस्टम इंटरैक्शन मज़बूत और गड़बड़ियों को सहने की क्षमता. अचानक होने वाले अनुरोध वे अनुरोध होते हैं जो कई बार भेजी जा सकती है, लेकिन इसका असर एक ही अनुरोध की तरह ही होता है. यह रणनीति अपनाकर, एक जैसा तरीका अपनाकर सिस्टम को एक जैसा रखा जा सकता है. सुरक्षित रखता है, जिससे हमारे सिस्टम संसाधन की स्थिति.

हमारा एपीआई, आइडिया में आने वाली जानकारी का इस्तेमाल इन कामों के लिए करता है:

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

ध्यान दें: गड़बड़ी के नतीजों को कभी भी कैश मेमोरी में सेव नहीं किया जाना चाहिए या उन्हें किसी भी तरीके से, आसानी से वापस नहीं किया जाना चाहिए. और, गड़बड़ियों के लिए अपने-आप होने वाली फिर से कोशिशों के लिए एक्स्पोनेंशियल बैकऑफ़ रणनीति का इस्तेमाल करना होगा.

उदाहरण

पहला उदाहरण: जवाब मिलने से पहले ही इंटरनेट कनेक्शन टूट गया

स्थिति:

1. Google, इंटिग्रेटर को अनुरोध भेजता है.
2. इंटिग्रेटर सर्वर को यह अनुरोध मिलता है और वह इसे प्रोसेस कर देता है.
3. चरण #2 में जवाब मिलने से पहले ही Google का सर्वर बंद हो जाता है.
4. Google का सर्वर पावर वापस लाया जाता है और वही अनुरोध भेजा जाता है सभी एक जैसे पैरामीटर के साथ (अनुरोध आईडी और अनुरोध की जानकारी एक ही है, लेकिन इसे अपडेट कर दिया गया है) requestTimestamp) को इंटीग्रेटर के सर्वर से लिंक किया जाएगा.

नतीजा:

इस मामले में इंटिग्रेटर सर्वर को वही जवाब देना होगा जो यहां दिया गया है चरण #2, क्योंकि responseTimestamp को छोड़कर बाकी सभी पैरामीटर एक जैसे हैं. साइड-इफ़ेक्ट, दूसरे चरण में सिर्फ़ एक बार दिखता है. चौथे चरण का कोई खराब असर नहीं होता.

दूसरा उदाहरण: ऐसे सर्वर को अनुरोध भेजा गया है जिसका रखरखाव किया जा रहा है

स्थिति:

1. इंटिग्रेटर सर्वर का डेटाबेस रखरखाव की वजह से काम नहीं कर रहा है.
2. Google, इंटिग्रेटर को अनुरोध भेजता है.
3. इंटिग्रेटर, सही तरीके से UNAVAILABLE स्टेटस कोड दिखाता है.
4. Google का सर्वर जवाब मिलता है और फिर से कोशिश शेड्यूल करता है.
5. इंटिग्रेटर सर्वर का डेटाबेस फिर से ऑनलाइन हो गया है.
6. Google, दूसरे चरण (एक ही अनुरोध आईडी और अनुरोध की जानकारी) से अनुरोध फिर से भेजता है लेकिन requestTimestamp अपडेट किया गया). ध्यान दें कि दोनों अनुरोधों के लिए अनुरोध आईडी एक जैसा होना चाहिए.
7. इंटिग्रेटर सर्वर को अनुरोध मिलता है और वह 'ठीक है' स्टेटस कोड दिखाता है पूरा जवाब दें.

नतीजा:

इस मामले में, इंटिग्रेटर सर्वर को चरण #7 में अनुरोध को प्रोसेस करना चाहिए, न कि एचटीटीपी 503 (UNAVAILABLE) दिखाएं. इसके बजाय, इंटिग्रेटर सर्वर को पूरी तरह से अनुरोध पर कार्रवाई करें और सही मैसेज भेजें. ध्यान दें कि हालांकि सिस्टम UNAVAILABLE है. Google इससे मिलते-जुलते अनुरोध बार-बार भी कर सकता है चरण #2. हर अनुरोध का मैसेज, चरण #3 जैसा होना चाहिए. आखिर में, चरण #6 और चरण #7 आएगा.

तीसरा उदाहरण: दोबारा कोशिश करने पर दिया गया मैसेज, खाता वापस पाने में हुई गड़बड़ी की वजह से पहले मैसेज से मेल नहीं खाता

स्थिति:

1. Google, इंटिग्रेटर को अनुरोध भेजता है.
2. इंटिग्रेटर सर्वर को यह अनुरोध मिलता है और वह इसे प्रोसेस कर देता है.
3. चरण #2 में जवाब मिलने से पहले ही Google का सर्वर बंद हो जाता है.
4. Google की सर्वर पावर फिर से चालू हो जाती है और वही अनुरोध भेजने की कोशिश करती है लेकिन दुर्भाग्य से कुछ पैरामीटर अलग हैं.

नतीजा:

इस मामले में, इंटिग्रेटर सर्वर को एचटीटीपी 412 के साथ जवाब देना चाहिए (PRECONDITION FAILED) गड़बड़ी कोड से यह पता चलता है कि Google को इस सिस्टम में गड़बड़ी है.