एकीकृत सेवाएं goszakup.gov.kz - संस्करण 2

मैं कंपनी सेंटर फॉर इलेक्ट्रॉनिक फाइनेंस JSC में डेवलपर के रूप में काम करता हूं।
हमारी एक परियोजना कजाकिस्तान गणराज्य की सार्वजनिक खरीद पोर्टल है - goszakup.gov.kz।

एक साल पहले, हमने एक बड़ी परियोजना शुरू की - यूनिफाइड सर्विसेज (ओपनडाटा)।
कार्यान्वयन के लिए, रेस्टापी पद्धति का उपयोग किया गया था।

आज मैं हमारी सेवाओं के नए संस्करण और उनके साथ काम करने के नए इंटरफ़ेस के बारे में बात करूंगा।



हमने 6 ओपन डेटा सेवाओं को विकसित और लॉन्च किया है:

• प्रतिभागियों का रजिस्टर
• बेईमान आपूर्तिकर्ताओं का रजिस्टर
• वार्षिक योजनाओं का रजिस्टर
• राज्य की घोषणा। प्राप्ति
• लॉट रजिस्टर
• ठेके की रजिस्ट्री

कजाकिस्तान में कई कंपनियां पहले से ही इन सेवाओं पर डेटा को कनेक्ट और प्राप्त कर रही हैं।
ओपन डेटा के लॉन्च ने हमें इस तथ्य के कारण डेटाबेस लोड को लगभग 40% कम करने की अनुमति दी कि कंपनियों को सार्वजनिक खरीद पर डेटा एकत्र करने के लिए विभिन्न पार्सर लिखने की आवश्यकता नहीं है। कठिन खोज से गुजरना काफी है :)

1. पहुँच टोकन के लिए एक अनुरोध लिखें
2. हमारे पोर्टल goszakup.gov.kz/ru/developer/ows पर सेवाओं के लिए प्रलेखन पढ़ें
3. अपने RestAPI क्लाइंट लिखें

एकीकृत सेवाएं - एक नया दृष्टिकोण

RestAPI किसी साइट को पार्स करने की तुलना में अधिक आसानी से और तेज़ी से डेटा प्राप्त करना संभव बनाता है, लेकिन मानक RestAPI कंपनियों को लचीलापन नहीं देता है और उन वस्तुओं के साथ संबंध बनाने के लिए आपको पहले सभी डेटा प्राप्त करने होते हैं और उसके बाद ही उनके बीच संबंध बनाते हैं।
एक घोषणा पर डेटा प्राप्त करने के लिए, RestAPI द्वारा पहले घोषणाओं के रजिस्टर, फिर बहुत सारे रजिस्टर और अंत में योजनाओं के रजिस्टर का अनुरोध करना आवश्यक है। इसका मतलब यह है कि एक घोषणा प्राप्त करने के लिए, कम से कम 3 अनुरोधों को पूरा करना आवश्यक है, और यदि आपको 50 विज्ञापनों पर डेटा प्राप्त करने की आवश्यकता है, तो आपको RestAPI को कम से कम 101 अनुरोधों की आवश्यकता होगी, बशर्ते कि प्रत्येक घोषणा में 1 लॉट (50 विज्ञापन प्राप्त करने के लिए, 50 प्राप्त करने के लिए 50, 50 प्राप्त करने के लिए 50) होंगे योजना के बिंदुओं की प्राप्ति)।

हमने इस राशि को एक अनुरोध पर कम करने का एक तरीका खोज लिया है!

हम एकीकृत सेवाओं - ows.goszakup.gov.kz/v2 का दूसरा संस्करण लॉन्च कर रहे हैं।
डेटासेट का विस्तार करने के अलावा, हम अपने एपीआई के साथ काम करने की क्षमता का विस्तार कर रहे हैं।

अब डेटा को रेस्टापी और नए इंटरफ़ेस के माध्यम से प्राप्त किया जा सकता है - ग्राफकॉल।
ows.goszakup.gov.kz/v2/graphql



मैं यह नहीं बताऊंगा कि ग्राफ़कॉग क्या है, इसके लिए आप ऑलसेंड लेख पढ़ सकते हैं - यह ग्राफ़कॉक क्या है?

मैं आपको बताऊंगा कि ग्राफकॉल शुरू करने के बाद हमें क्या फायदे हुए:

• लचीलापन का अनुरोध करें;
• संबंधित वस्तुएं प्राप्त करना;
• अनुरोधों और प्रतिक्रियाओं का पूरा टाइपिंग;
• नया डेटा खोज इंटरफ़ेस।

लचीलापन का अनुरोध करें

एक साधारण RestAPI अनुरोध के साथ, आपको वह डेटा प्रारूप मिलता है जिसे पहले से रखा गया था।
जब आप GraphQL से क्वेरी करते हैं, तो आपको उस प्रारूप में डेटा मिलता है जिसकी आपको आवश्यकता होती है।

डेटा का अनुरोध करते समय, आप स्वयं उस डेटा का प्रारूप निर्धारित करते हैं जिसकी आपको आवश्यकता है, उदाहरण के लिए, आईडी और

अनुबंध संख्या

{ contract { id contract_number_sys } } 

जवाब में, हमें केवल यह डेटा मिलता है:

 { "data": { "contract": [ { "id": 1, "contract_number_sys": "_" } ] } } 

वैसे, इस तरह के क्वेश्चन ग्राफकॉल को लागू करना सबसे आसान है। कंपनियों को यह चुनने का अवसर दिया जाता है कि वे कौन सा डेटा प्राप्त करना चाहती हैं, जबकि हमें कोई समायोजन करने की आवश्यकता नहीं है जैसे कि यह जब रेस्टापी के साथ काम कर रहे थे। आपको केवल उन फ़ील्ड्स का सेट मिलता है जिनकी आवश्यकता है।

संबंधित वस्तुओं को पुनः प्राप्त करना

हमने रेस्टापी की कार्यक्षमता को केवल आंशिक रूप से डेटा का चयन करके संभव बनाने पर रोक नहीं लगाई।

हमने ग्राफ़क्यूल - ऑब्जेक्ट रिलेशनशिप की दूसरी विशेषता को लागू किया है।

यदि आप अनुबंध और कंपनी पर डेटा प्राप्त करने के लिए, रेस्टापी के अनुसार डेटा प्राप्त करते हैं, तो अनुबंध में ग्राहक को पहले प्रतिभागियों के रजिस्टर से डेटा प्राप्त करना होगा, और उसके बाद ही अनुबंध के रजिस्टर से डेटा प्राप्त करना होगा और वस्तुओं के बीच संबंध बनाना होगा।

अब, जब ग्राफकॉल के साथ काम करते हैं, तो आपको प्रतिभागी रजिस्टर से पूरी तरह से डेटा प्राप्त करने की आवश्यकता नहीं है, बस उस प्रारूप में डेटा का अनुरोध करें जिसमें आप रुचि रखते हैं:

 { contract { id contract_number_sys customer { name_ru } } } 

इस प्रकार, एक अनुरोध के साथ, हम ग्राहक के लिए अनुबंध डेटा और कंपनी डेटा दोनों प्राप्त करते हैं:

 { "data": { "contract": [ { "id": 1, "contract_number_sys": "_", "customer" : { "name_ru": " " } } ] } } 

और कई ऐसे रिश्ते हैं जो लागू किए गए हैं; अब डेटा प्राप्त करने के लिए कंपनियों को डेटा के लिए बहुत कम अनुरोधों की आवश्यकता होगी। उसी समय, किसी को अब यह अनुमान लगाने की आवश्यकता नहीं है कि ऑब्जेक्ट एक-दूसरे से कैसे संबंधित हैं, उन्हें एक-दूसरे से जोड़ने के लिए पूरा डेटा सेट प्राप्त करें।

मैंने कनेक्शन संरचना को आंशिक रूप से प्रदर्शित करने की कोशिश की, जिसे मैं हासिल करने में कामयाब रहा।

अनुरोधों और प्रतिक्रियाओं को टाइप करना

SOAP अनुरोधों के कई समर्थकों ने हमेशा सबसे महत्वपूर्ण प्लस - डेटा टाइपिंग को रखा है।
SOAP के विपरीत, RestAPI में इसकी संरचना का विवरण नहीं है और आप पहले से नहीं जानते हैं कि डेटा किस प्रकार का है। लेकिन GraphQL सब कुछ बदल देता है।

अब आप पूरे डेटा स्कीम में ग्राफकॉल से डेटा का अनुरोध कर सकते हैं और आपको प्राप्त होगा:

• डेटा संरचना का पूर्ण विवरण;
• किस क्षेत्र का विवरण एक डेटा प्रकार (इंट, स्ट्रिंग, बूलियन) है;
• नेस्टेड ऑब्जेक्ट्स और नेस्टेड ऑब्जेक्ट्स के फील्ड स्ट्रक्चर का विवरण;
• विस्तृत विवरण, उदाहरण के लिए, प्रत्येक क्षेत्र के लिए रूसी में;
• एक अधिसूचना प्राप्त करें कि कुछ फ़ील्ड को विवरण के साथ डिप्रेस्ड ध्वज प्राप्त हुआ है।

मैं ग्राफ़िकल के साथ काम करने के लिए अनिद्रा रस्ट क्लाइंट प्रोग्राम - insomnia.rest का उपयोग करता हूं
ग्राफक्लाइन के साथ काम करते समय, यह एक क्वेरी बनाते समय ऑब्जेक्ट्स की पूरी संरचना और संकेत देता है।

मैं एक उदाहरण के रूप में कुछ स्क्रीनशॉट दे दूंगा।

1. प्रश्नों के निर्माण में मदद करना कार्यक्रम को वस्तुओं की एक पूरी संरचना प्राप्त हुई



2. प्रत्येक क्षेत्र के विवरण के लिए उसके डेटा प्रकार और विवरण के साथ संकेत



3. संकेत अगर किसी क्षेत्र को एक झंडा मिला है - पदावनत



और GraphQL की यह सुविधा आपको उन क्षेत्रों और वस्तुओं की पूरी तस्वीर रखने की अनुमति देती है जिनके साथ आप काम करते हैं।

नया डेटा पुनर्प्राप्ति इंटरफ़ेस

और मैंने अंत में सबसे दिलचस्प छोड़ दिया।

सब कुछ शांत लग रहा है, अपनी खुद की डेटा संरचना का निर्माण करना संभव है, अन्य वस्तुओं के साथ एक संबंध है, सभी डेटा टाइप किया गया है। लेकिन फिर भी कुछ याद आ रहा है ...

इस डेटा पर खोज करने के लिए पर्याप्त अवसर नहीं है।

शुरुआत में, अनुरोध में मापदंडों के साथ एक खोज प्रारूप लागू किया गया था:

 { trd_buy(ref_buy_status_id: 1) { name_kz name_ru } } 

लेकिन यहाँ मैं कई समस्याओं में भाग गया:

1. बड़ी संख्या में खोज मापदंड के साथ, क्वेरी बस अपठनीय हो जाती है;
2. एक ही क्षेत्र के कई प्रकारों को खोजने के लिए डेटा की खोज करते समय सरणी को निर्धारित करना असंभव है।

प्रश्नों के निर्माण को सरल बनाने के लिए, और खोज क्षमता का विस्तार करने के लिए, मैंने डेटा को फ़िल्टर करने के लिए नेस्टेड ऑब्जेक्ट्स को लागू किया।

हम फ़िल्टरिंग ऑब्जेक्ट को इंगित करने वाले अनुरोध में एक चर को परिभाषित करते हैं।

 query($filter: TrdBuyFiltersInput){ trd_buy(filters: $filter) { name_kz name_ru } } 

हम स्वयं डेटा खोज मापदंडों का वर्णन करते हैं:

 { "filter": { "ref_buy_status_id": [1, 2] } } 

और परिणामस्वरूप, हमें वे सभी विज्ञापन प्राप्त होंगे जिनकी स्थिति 1 और 2 है।

अनुरोध में ही, हम केवल डेटा संरचना को इंगित करते हैं, और सभी खोज पैरामीटर मापदंडों के संचरण में जाते हैं जहां हम पहले से ही कई मानदंडों के अनुसार फ़िल्टर करने के लिए डेटा सरणियों को स्थानांतरित कर सकते हैं।



इसके अलावा, ग्राफकाइ स्कीमा में, हम सभी के पास इस तरह की खोज वस्तु का विवरण भी है:

एकीकृत सेवाएँ - संस्करण 2.0:

सेवा कार्य:

• प्रतिभागियों का रजिस्टर
• घोषणाओं की रजिस्ट्री
• ठेके की रजिस्ट्री
• कृत्यों का रजिस्टर
• लॉट रजिस्टर
• वार्षिक योजनाओं का रजिस्टर
• बेईमान आपूर्तिकर्ताओं का रजिस्टर

हमने एक नई कार्यक्षमता शुरू की, जो हमारे एपीआई के साथ काम करने को सरल बनाती है, इसमें एक लचीली क्वेरी संरचना और निर्दिष्ट मानदंडों के अनुसार डेटा की खोज करने की क्षमता है।

हम डेटा प्राप्त करने की गति में नहीं खोए हैं, लेकिन केवल इस वजह से कम करते हैं कि डेटा प्राप्त करने के लिए आवश्यक अनुरोधों की संख्या।

हम अक्षम या पुनर्नामित फ़ील्ड के बारे में डेटा स्कीमा में चेतावनी देने में सक्षम थे।

हम एपीआई को और विकसित करने और सेवाओं पर डेटा के रूपात्मक खोज को सक्षम करने की योजना बना रहे हैं।