Product-apim: ग्राफिकल के लिए समर्थन

+1

+1

+1

+1

+1

+1

:+1:

हाय @YannickB ,

इस बात की जानकारी देने के लिए धन्यवाद। हम इसे अपने रोडमैप में जोड़ना चाहेंगे।

मैंने ग्राफ़क्यूएल का अधिक उपयोग नहीं किया है और इसलिए आवश्यकता के सटीक दायरे को समझने में कुछ परेशानी हो रही है। कुछ स्पष्टता के लिए, क्या आप एक उदाहरण का उपयोग करके वर्तमान कार्यक्षमता की सटीक सीमाओं की व्याख्या कर सकते हैं? मूल रूप से अपोलो सर्वर के माध्यम से क्या उजागर किया गया है और आज आपको एपीआई गेटवे के माध्यम से इसे कैसे उजागर करना होगा बनाम एपीआई गेटवे के माध्यम से इसे उजागर करने का आदर्श तरीका क्या होगा।

धन्यवाद,
नुवान।

+1

हाय @नुवंद ,

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

मैं सहमत हूं कि समझाने का सबसे अच्छा तरीका एक उदाहरण होगा, इसलिए यहां यह है:

मान लें कि आपके पास दो ऑब्जेक्ट, उत्पाद और इनवॉइस के लिए CRUD फ़ंक्शन प्रदान करने वाला API है।

एक रेस्ट एपीआई के साथ, आपके पास उपयोग करने के लिए दो एंडपॉइंट होंगे, http://myapi.com/api/product और http://myapi.com/api/invoice , और फिर आप GET/POST/PUT/DELETE ऑपरेशन करते हैं उन पर।
WSO2 में, आप प्रत्येक समापन बिंदु को स्वतंत्र रूप से कॉन्फ़िगर कर सकते हैं, एक उत्पाद के लिए और एक इनवॉइस के लिए, और फिर उनमें से प्रत्येक के लिए WSO2 द्वारा प्रदान की गई सुरक्षा/थ्रॉटलिंग/मुद्रीकरण/आदि... सुविधाओं को स्वतंत्र रूप से प्रबंधित करने के लिए एक विशिष्ट कॉन्फ़िगरेशन दे सकते हैं।

लेकिन अगर हम एक ग्राफक्यूएल एपीआई प्रदान कर रहे हैं तो हम वर्तमान में बहुत अधिक सीमित हैं। यह इस तथ्य के कारण है कि दोनों वस्तुएं एक ही समापन बिंदु http://myapi.com/graphql में पहुंच योग्य होंगी। और कई समापन बिंदु बनाने का कोई तरीका नहीं है http://myapi.com/graphql/product और http://myapi.com/graphql/invoice , यह ग्राफक्यूएल की सर्वोत्तम प्रथाओं के साथ पूरी तरह से विरोधी पैटर्न है और सबसे अधिक बना देगा इसके पारिस्थितिकी तंत्र में उपकरण काम करना बंद कर देते हैं। इसके अलावा, मेरा मानना ​​​​है कि सभी HTTP ऑपरेशन POST हैं।

तो उदाहरण के तौर पर, हम GraphQL एंडपॉइंट पर शोध अनुरोध करना चाह सकते हैं:

query {
  product(id: 1) {
    id
    name
  }
}

mutation {
  createInvoice(data: {
    'customerID': 1
    'productID': 1
    'price': 20
  }) {
    id
    number
    total
  }
}

पहला अनुरोध निर्दिष्ट उत्पाद की जानकारी को क्वेरी करेगा, और दूसरा इस उत्पाद के लिए एक चालान बनाएगा। दोनों प्रश्नों को http://myapi.com/graphql एंडपॉइंट पर निष्पादित किया जाता है।

तो WSO2 गेटवे की वर्तमान स्थिति के साथ, जो कि अगर मैं गलत नहीं हूं, तो केवल प्रति समापन बिंदु को कॉन्फ़िगर करने की अनुमति देता हूं, यदि मैं उदाहरण के लिए http://myapi.com/graphql एंडपॉइंट को कॉन्फ़िगर करके इनवॉइस बनाने के लिए प्रत्येक कॉल को 0.01cent पर मुद्रीकृत करना चाहता हूं, तो उत्पाद के लिए कॉल भी 0.01cent पर मुद्रीकृत किया जाएगा। आरईएसटी के साथ, आप पोस्ट पर 0.01cent को http://myapi.com/api/invoice पर कॉन्फ़िगर करेंगे और यह सब कुछ होगा।
मुझे आशा है कि यह आपके लिए मेरी बात को समझने के लिए पर्याप्त है, यह एक सरल उदाहरण है लेकिन हम बहुत से अन्य पा सकते हैं, वर्तमान स्थिति में कॉन्फ़िगरेशन में लचीलेपन की कमी के कारण ग्राफ़क्यूएल के साथ गेटवे सुविधाओं का उपयोग करना असंभव है। और यह आपकी गलती नहीं है, मेरा मानना ​​है कि बाजार में अन्य सभी एपीआई गेटवे में एक ही समस्या है।

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

ऐसा लगता है कि इस सुझाव ने काफी ध्यान आकर्षित किया। इस मुद्दे का अनुसरण करने वाले लोगों के लिए, मैं आपको अपने उपयोग के मामले के बारे में कुछ जानकारी देने के लिए आमंत्रित करता हूं और WSO2 को इस सुविधा को कैसे डिज़ाइन करना चाहिए। मुझे आशा है कि मैंने स्थिति का वर्णन करने के लिए अपनी पूरी कोशिश की है, लेकिन मेरा मानना ​​है कि इसे ठीक से लागू करने के लिए उन्हें कुछ वास्तविक उदाहरण की आवश्यकता होगी।

सादर,
यानिक

अस्थायी समाधान के रूप में एपीआई गेटवे में पूर्ण समर्थन की प्रतीक्षा करते समय इसे सेवा निर्देशिका के रूप में उपयोग करने के लिए WSO2-AM ग्राफ़िकल एंडपॉइंट्स में आयात करने की कम से कम संभावना होना बहुत अच्छा होगा

हाय @YannickB ,

आपके स्पष्टीकरण के लिए धन्यवाद। मुझे क्षमा करें, लेकिन मैं अभी भी अंतिम बिंदुओं के साथ सीमाओं का पता लगाने की कोशिश कर रहा हूं। मुझे समापन बिंदुओं के संबंध में एपीआई प्रबंधक की क्षमता की व्याख्या करने दें और फिर शायद आप सीमा को इंगित कर सकते हैं।

मान लें कि आपके पास http://myapi.com/api/invoice और http://myapi.com/api/product जैसे दो अंतिम बिंदु हैं। ध्यान दें कि मैं उसी उदाहरण का उपयोग कर रहा हूं जैसा आपने किया था, जिस पर दोनों समापन बिंदु एक ही होस्ट (myapi.com) पर प्रतीत होते हैं। यदि आपकी आवश्यकता दोनों समापन बिंदुओं को प्रॉक्सी करने के लिए API प्रबंधक पर एक एकल API की है, तो आपको दो संसाधन बनाने होंगे, एक POST /invoice के रूप में और दूसरा POST /उत्पाद के रूप में और http://myapi.com/ निर्दिष्ट करें।

पोस्ट http://gateway.myqpi.com/graphql/1.0.0/invoice -> पोस्ट http://myqpi.com/api/invoice
पोस्ट http://gateway.myqpi.com/graphql/1.0.0/product -> पोस्ट http://myqpi.com/api/product

ध्यान दें कि आपको दोनों एंडपॉइंट को प्रॉक्सी करने के लिए केवल 1 API (/graphql/1.0.0) बनाना होगा। मुझे खेद है कि अगर मैं कुछ ऐसा दोहरा रहा हूं जो आप पहले से जानते हैं :), लेकिन अगर आप मानचित्रण के लिए हमारे संसाधन पर सीमा को इंगित कर सकते हैं जिससे ग्राफ़क्यूएल का उपयोग करना असंभव हो जाता है जो मुझे समस्या को बेहतर ढंग से समझने में मदद करेगा।

धन्यवाद,
नुवान।

नुवांड, मैं तुमसे कम तकनीकी हूँ। लेकिन एक एपीआईएम/पहचान सर्वर के साथ मेरी समझ में हम एपीआई स्तर पर एक एपीआई (सुरक्षा, थ्रॉटलिंग, ... ..) के प्रबंधन को परिभाषित करते हैं। ग्राफक्यूएल एक तरह की 'सुपर' भाषा है जो एपीआई को 'मेटा' भाषा के माध्यम से जोड़ती है। मेरी दिलचस्पी यह समझने में होगी कि ग्राफ़क्यूएल की अवधारणाएँ और WS02 APIM की अवधारणाएँ कैसे मेल खाती हैं। और अगर दोनों अवधारणाओं को एकीकृत किया जाएगा। ऑफकोर्स आप ग्राफ़क्यूएल अल्स 1 संसाधन पर विचार कर सकते हैं जो स्वयं सबकुछ प्रबंधित करता है .... लेकिन डब्लूएस02 के मूल्य से सीमित है यदि मेरी सभी 'विरासत' सेवाएं ग्राफ़िकल सर्वर के माध्यम से पहुंच योग्य होंगी।

+1

ग्राफक्यूएल के साथ, वास्तव में केवल एक ही समापन बिंदु है, इसलिए myapi.com/graphql/invoice और graphql/product जैसी कोई चीज नहीं है, एंडोइंट सिर्फ "myapi.com/graphql" है, और उसके बाद कुछ भी नहीं है। अनुरोध के शरीर के अंदर परिभाषित संचालन के साथ, यह प्रत्येक क्वेरी और उत्परिवर्तन के लिए सचमुच एक ही यूआरएल है।

कुछ एपीआई प्रबंधन सुविधाओं के लिए अनुरोध निकाय के आत्मनिरीक्षण की आवश्यकता होगी, ग्राफ़िकल स्कीमा का ज्ञान, आदि। आइए मान लें कि यह अल्पावधि पर _not_ व्यवहार्य है: WSO2 लगभग अपने आप में एक ग्राफ़क्यूएल सर्वर/गेटवे बन जाना चाहिए (या एक को एकीकृत करना)।

इसके बजाय, हमें इस बात पर ध्यान देना चाहिए कि कौन सी API प्रबंधन सुविधाएं _are_ संभव हैं। मुझे लगता है कि हमें WSO2 और वास्तविक GraphQL सर्वर/गेटवे के बीच सहयोग की आवश्यकता है, उदाहरण के लिए हेडर सेट करके। उदाहरण के लिए मुद्रीकरण: ग्राफ़क्यूएल सर्वर क्वेरी की जटिलता की गणना कर सकता है, इस जानकारी को प्रतिक्रिया में HTTP हेडर के रूप में जोड़ सकता है, जहां WSO2 इस मान को एक मूल्य में अनुवादित करता है। इसी तरह निगरानी के लिए, ग्राफ़क्यूएल सर्वर जेएसओएन-आकार की क्वेरी को (एक सूची) आराम-जैसे छद्म-समापन बिंदु (ओं) में 'रूपांतरित' कर सकता है, जिसे WSO2 निगरानी जानकारी को अद्यतन करने के लिए प्रतिक्रिया शीर्षलेख से पढ़ता है। सुरक्षा के लिए एक ही काम किया जा सकता है, शायद 2 चरणों में: पहले ग्राफ़क्यूएल सर्वर से क्वेरी को रेस्ट-लाइक एंडपॉइंट्स में बदलने के लिए कहें, WSO2 पास करने या न करने का फैसला करता है, क्वेरी को वास्तविक एंडपॉइंट पर अग्रेषित करता है।

मैं WSO2 के लिए पूरी तरह से नया हूं और अधिकांश दस्तावेज़ीकरण नहीं पढ़ा है, इसलिए हो सकता है कि ये सुविधाएँ पहले से ही WSO2 में हों (अधिक विशेष रूप से: WSO2 की किसी भी कार्यक्षमता के लिए जो आमतौर पर सटीक REST समापन बिंदु URI से ली गई है, चाहे वह वही कार्यक्षमता हो वैकल्पिक तरीके से व्युत्पन्न किया जा सकता है (उदाहरण के लिए एक शीर्षलेख मान या WSO2 के लिए कोई अन्य API))। यह संभावना है कि इन WSO2- विशिष्ट सुविधाओं का समर्थन करने के लिए एक GraphQL सर्वर को संशोधित करने की आवश्यकता है। सवाल यह है कि हम किस कम लटके हुए फल से शुरुआत कर सकते हैं?

(बेशक मैं WSO2 को ग्राफ़क्यूएल में एक बड़ी प्रतिबद्धता देखना चाहता हूं ...

अच्छी प्रतिक्रिया, मुझे भी ऐसा ही लगता है;)

ऑप डी 6 नवंबर। 2018 दोपहर 12:06 श्राफ चौथा44 नोटिफिकेशन @github.com :

GraphQL के साथ, वास्तव में केवल एक ही समापन बिंदु है, इसलिए ऐसा कोई नहीं है
myapi.com/graphql/invoice और graphql/product जैसी चीज, एंडोइंट है
बस "myapi.com/graphql", और उसके बाद कुछ भी नहीं। यह वस्तुतः है
प्रत्येक क्वेरी और उत्परिवर्तन के लिए एक ही यूआरएल, अंदर परिभाषित संचालन के साथ
अनुरोध का शरीर।

कुछ एपीआई प्रबंधन सुविधाओं के लिए आत्मनिरीक्षण की आवश्यकता होगी
अनुरोध निकाय, ग्राफ़िकल स्कीमा का ज्ञान, आदि। आइए मान लें कि यह
अल्पावधि में संभव नहीं है: WSO2 लगभग एक GraphQL बन जाना चाहिए
सर्वर/गेटवे अपने आप में (या एक को एकीकृत करें)।

इसके बजाय, हमें इस बात पर ध्यान देना चाहिए कि कौन सी एपीआई प्रबंधन सुविधाएं संभव हैं ।
मुझे लगता है कि हमें WSO2 और वास्तविक GraphQL के बीच सहयोग की आवश्यकता है
सर्वर/गेटवे, उदाहरण के लिए हेडर सेट करके। उदाहरण के लिए मुद्रीकरण: the
GraphQL सर्वर क्वेरी की जटिलता की गणना कर सकता है, इसे जोड़ें
प्रतिक्रिया के लिए HTTP शीर्षलेख के रूप में जानकारी, जहां WSO2 इसका अनुवाद करता है
एक मूल्य में मूल्य। इसी तरह निगरानी के लिए, GraphQL सर्वर कर सकता है
जेएसओएन-आकार की क्वेरी को 'कन्वर्ट' करें (एक सूची) बाकी की तरह
छद्म-समापन बिंदु, जिसे WSO2 अद्यतन करने के लिए प्रतिक्रिया शीर्षलेख से पढ़ता है
निगरानी की जानकारी। सुरक्षा के लिए भी ऐसा ही किया जा सकता है, शायद 2
चरण: पहले ग्राफक्यूएल सर्वर से क्वेरी को रेस्ट-लाइक में बदलने के लिए कहें
समापन बिंदु, WSO2 पास करने या न करने का निर्णय लेता है, क्वेरी को वास्तविक पर अग्रेषित करता है
समापन बिंदु

मैं WSO2 के लिए पूरी तरह से नया हूं और अधिकांश दस्तावेज़ीकरण नहीं पढ़ा है, इसलिए
हो सकता है कि ये सुविधाएँ पहले से ही WSO2 में हों (अधिक विशेष रूप से: किसी के लिए भी)
WSO2 की कार्यक्षमता जो आमतौर पर सटीक REST समापन बिंदु से ली गई है
यूआरआई, क्या वही कार्यक्षमता वैकल्पिक तरीके से प्राप्त की जा सकती है
(उदाहरण के लिए WSO2 के लिए हेडर वैल्यू या कोई अन्य एपीआई))। ऐसी संभावना है
इन WSO2- विशिष्ट का समर्थन करने के लिए एक GraphQL सर्वर को संशोधित करने की आवश्यकता है
विशेषताएं। सवाल यह है कि हम किस कम लटके हुए फल से शुरुआत कर सकते हैं?

(बेशक मैं WSO2 को ग्राफ़क्यूएल में एक बड़ी प्रतिबद्धता देखना चाहता हूं ...
लेकिन हमें कहीं न कहीं शुरुआत करने की ज़रूरत है, है ना?)

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/wso2/product-apim/issues/3184#issuecomment-436215537 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/Ad4tuNmWvNcpkc1Nk5y46DljcQeM9RPwks5usW0kgaJpZM4TLf2Q
.

--
बार्ट वैन वेलियरबेर्गे

नमस्ते,
यहाँ अपोलो सर्वर प्रलेखन का एक अंश दिया गया है:
_"यदि आप एक REST API का उपयोग कर रहे हैं जिसमें अंतर्निहित प्राधिकरण है, जैसे HTTP शीर्षलेख के साथ, तो आपके पास एक और विकल्प है। GraphQL परत (रिज़ॉल्वर/मॉडल में) में कोई प्रमाणीकरण या प्राधिकरण कार्य करने के बजाय, यह संभव है हेडर या कुकीज को अपने आरईएसटी एंडपॉइंट पर बस पास करने के लिए और इसे काम करने दें।"_
यदि आपके ग्राफ़िकल प्रश्नों में शामिल सभी समापन बिंदुओं के लिए एपीआई कुंजी समान है, तो ऐसा लगता है कि यह चाल चल सकती है।
इस "वर्कअराउंड" के बारे में कोई विचार (अपोलो सर्वर को एपीआई-एम के सामने रखें)?

आवश्यकता विश्लेषण

• ग्राफक्यूएल को फेसबुक द्वारा विकसित किया गया है जो आरईएसटी का एक विकल्प है। यह एपीआई के लिए एक क्वेरी भाषा है जहां एक विशेष उपयोगकर्ता यह निर्दिष्ट कर सकता है कि एपीआई से किस डेटा की आवश्यकता है।
• हम जानते हैं कि हम REST API को डिज़ाइन करने के लिए स्वैगर डेफिनिशन (ओपन एपीआई स्पेसिफिकेशन) का उपयोग कर सकते हैं। लेकिन ग्राफक्यूएल में, हम ग्राफक्यूएल एपीआई के लिए स्कीमा लिखने के लिए स्कीमा डेफिनिशन लैंग्वेज (एसडीएल) का उपयोग कर सकते हैं।
• ग्राफ़क्यूएल एपीआई को लागू करने का सीधा मतलब है कि ग्राफक्यूएल प्रश्नों का उपयोग करके डेटा प्राप्त करना और ग्राफक्यूएल म्यूटेशन का उपयोग करके डेटा लिखना।
• यहाँ पर हमारी आवश्यकता WSO2 APIM से सहायता देने की है ताकि एक GraphQL API बनाया और प्रकाशित किया जा सके और इसे https/http पर लागू किया जा सके।

सुझाया गया दृष्टिकोण

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

• अगला, कार्यान्वयन टैब में, यदि उपयोगकर्ता चयन करता है,

  • एपीआई प्रबंधित करें

    • समापन बिंदु प्रकार को स्वचालित रूप से HTTP/REST समापन बिंदु पर सेट किया जाना चाहिए। (उपयोगकर्ता के पास इसे बदलने की क्षमता नहीं होनी चाहिए)
    • उपयोगकर्ता के पास हमेशा की तरह एंडपॉइंट (उत्पादन और सैंडबॉक्स) को बदलने की क्षमता होनी चाहिए।
    • अन्य फ़ील्ड समान रहना चाहिए।
      

  • प्रोटोटाइप एपीआई

    • इनलाइन कार्यान्वयन पद्धति में, दो GET और POST विधियों को स्वचालित रूप से बनाया और प्रदर्शित किया जाना चाहिए जैसा कि निम्नलिखित स्क्रीनशॉट में दिखाया गया है।
      

• यदि आप मैनेज एपीआई विकल्प चुनते हैं तो आपको मैनेज टैब में सेटिंग्स को सेट करना होगा।

  • यहां भी यही प्रक्रिया अपनानी होगी।
  • विशेष रूप से इनलाइन प्रोटोटाइप पद्धति की तरह, दो GET और POST विधियों को स्वचालित रूप से बनाया और प्रदर्शित किया जाना चाहिए जैसा कि निम्नलिखित स्क्रीनशॉट में दिखाया गया है।
    

• एपीआई प्रकाशित या प्रोटोटाइप के बाद

  • एपीआई स्टोर में एपीआई को ग्राफक्यूएल एपीआई के रूप में लेबल किया जाना चाहिए।
  • एक उपभोक्ता के पास एपीआई स्टोर के माध्यम से उस एपीआई की स्कीमा फाइल को डाउनलोड करने की क्षमता होनी चाहिए।

अच्छा लग रहा है

@wasuradananjith क्या आप यह भी पोस्ट कर सकते हैं कि स्टोर में ग्राफ़क्यूएल एपीआई कैसा दिखता है? क्या एपीआई पोर्टल में क्वेरी उपलब्ध है, शायद स्कीमा के साथ?

कम से कम अपोलो ग्राफक्यूएल डेटा अनुरोध के लिए जीईटी का उपयोग करने का समर्थन करता है।

नमस्ते,

कृपया WSO2 APIM 3.0.0 रिलीज़ से संबंधित ग्राफ़िकल समर्थन की जानकारी और पीआर प्राप्त करें। चूंकि हम एक नए रिएक्ट-आधारित UI के तहत WSO2 APIM 3.0.0 जारी करने जा रहे हैं, इसलिए नए UI के स्क्रीनशॉट निम्नानुसार जोड़े गए हैं।

एपीआई प्रकाशक
विवरण:
जब एपीआई क्रिएटर ग्राफक्यूएल स्कीमा को एपीआई पब्लिशर में अपलोड करता है, तो पब्लिशर पोर्टल में क्वेरी और म्यूटेशन ऑपरेशंस को लिस्ट किया जाएगा। फिर वह कार्यक्षेत्रों को परिभाषित करने, नीतियों को थ्रॉटलिंग करने, संचालन के विरुद्ध सुरक्षा को सक्षम/अक्षम करने की अनुमति देगा।

प्रकाशक पर कार्य।

1. GraphQL SDL स्कीमा आयात करके एक GraphQL API बनाएं
2. स्कीमा को मान्य करें और इसके संचालन को स्कीमा परिभाषा से निकालें
3. प्रकाशक पर एसडीएल स्कीमा को पुनः प्राप्त/आयात/डाउनलोड करें।
4. संसाधनों के बजाय संचालन दिखाता है
5. थ्रॉटलिंग, दायरे, संचालन के खिलाफ सुरक्षा जोड़ें/अपडेट करें
6. API लिस्टिंग पेज पर 'GRAPHQL' लेबल करने वाले ग्राफ़क्यूएल एपीआई देखें

एपीआई स्टोर
एक बार प्रकाशक उपयोगकर्ता द्वारा एपीआई प्रकाशित करने के बाद, एसडीएल स्कीमा में सभी संचालन डेवलपर पोर्टल पर पॉप्युलेट हो गए हैं और स्कीमा फ़ाइल डाउनलोड करने के लिए भी उपलब्ध है। डेवलपर GET और POST अनुरोध प्रकारों के साथ Tryout कंसोल का उपयोग करके संचालन का परीक्षण कर सकता है।

दुकान पर कार्यक्षमता।

1. API लिस्टिंग पेज पर 'GRAPHQL' लेबल करने वाले ग्राफ़क्यूएल एपीआई देखें
2. विशेष एपीआई के लिए संचालन देखें
3. स्कीमा प्राप्त करने वाले एसडीएल स्कीमा को डाउनलोड करने में सक्षम
4. एपीआई को लागू करने के लिए GET और POST के साथ डेवलपर कंसोल प्रदान करें

दृश्यों का स्क्रीनशॉट

1. GrpahQL API पेज बनाएं
   

1. स्कीमा पेज अपलोड करें
   

2. अगला क्लिक करें और विवरण भरने के लिए एक फॉर्म भरें
   

3. ग्राफक्यूएल एपीआई अवलोकन पृष्ठ बनाया गया
   

4. ग्राफक्यूएल एपीआई ऑपरेशन व्यू
   

5. अपलोड की गई स्कीमा परिभाषा
   

6. स्कोप, थ्रॉटलिंग, सुरक्षा जोड़ें / अपडेट करें
   

7. स्टोर संचालन अवलोकन
   

8. स्कीमा डाउनलोड
   

9. डेवलपर कंसोल
   

ग्राफ़िकल एपीआई का आह्वान समय

1. प्राधिकरण - एपीआई क्रिएटर प्रकाशक के हर ऑपरेशन में स्कोप जोड़ सकता है
   जब एपीपी उपयोगकर्ता ग्राफक्यूएल एपीआई को क्वेरी/म्यूटेशन (केवल-पढ़ने/पढ़ने-लिखने) ऑपरेशन के साथ आमंत्रित करता है, तो एपीआई गेटवे पहचान करेगा कि कौन से ऑपरेशन पेलोड में हैं और उपयोगकर्ता के टोकन स्कोप के अनुसार उनका मिलान करें। यदि पेलोड में कई स्कोप के साथ कई ऑपरेशन होते हैं, तो टोकन में कम से कम ऑपरेशन स्कोप का एक संघ होना चाहिए।
   उदाहरण: - मान लें कि जब कोई प्रश्न होता है, (ऑपरेशन ए - स्कोप 1, ऑपरेशन बी - स्कोप 2)
   क्वेरी को निष्पादित करने वाले उपयोगकर्ता के टोकन में दोनों स्कोप (स्कोप 1 और स्कोप 2) होने चाहिए

2. सुरक्षा - एपीआई क्रिएटर प्रकाशक के हर ऑपरेशन में सुरक्षा को सक्षम/अक्षम कर सकता है।
   जब एक क्वेरी अनुरोध कई ऑपरेशन नामों के साथ आता है, तो सुरक्षा को संचालन सुरक्षा का संघ माना जाता है। यदि एक ऑपरेशन को सुरक्षा सक्षम किया गया है, तो हम पूरे अनुरोध के लिए सुरक्षा का समर्थन करते हैं।

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

पीआर https://github.com/wso2/carbon-apimgt/pull/6784 पर मिलेगा।

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

1. https://github.com/wso2/product-apim/issues/5432
2. https://github.com/wso2/product-apim/issues/5431
3. https://github.com/wso2/product-microgateway/issues/773
4. https://github.com/wso2/analytics-solutions/issues/310

इस संबंध में अपने विचारों और मूल्यवान इनपुट की सराहना करें।

धन्यवाद!

नमस्ते,

कृपया WSO2 APIM 3.0.0 रिलीज़ से संबंधित ग्राफ़िकल समर्थन की जानकारी और पीआर प्राप्त करें। चूंकि हम एक नए रिएक्ट-आधारित UI के तहत WSO2 APIM 3.0.0 जारी करने जा रहे हैं, इसलिए नए UI के स्क्रीनशॉट निम्नानुसार जोड़े गए हैं।

एपीआई प्रकाशक
विवरण:
जब एपीआई क्रिएटर ग्राफक्यूएल स्कीमा को एपीआई पब्लिशर में अपलोड करता है, तो पब्लिशर पोर्टल में क्वेरी और म्यूटेशन ऑपरेशंस को लिस्ट किया जाएगा। फिर वह कार्यक्षेत्रों को परिभाषित करने, नीतियों को थ्रॉटलिंग करने, संचालन के विरुद्ध सुरक्षा को सक्षम/अक्षम करने की अनुमति देगा।

प्रकाशक पर कार्य।

1. Create a GraphQL APIs by importing GraphQL SDL schema

2. Validate the schema and extract its operations from the schema definition

3. Retrieve/Import/Download  SDL schema at the publisher.

4. Shows operations instead of resources

5. Add/Update throttling,scopes,security against operations

6. View graphQL APIs labeling 'GRAPHQL' at API Listing Page

एपीआई स्टोर
एक बार प्रकाशक उपयोगकर्ता द्वारा एपीआई प्रकाशित करने के बाद, एसडीएल स्कीमा में सभी संचालन डेवलपर पोर्टल पर पॉप्युलेट हो गए हैं और स्कीमा फ़ाइल डाउनलोड करने के लिए भी उपलब्ध है। डेवलपर GET और POST अनुरोध प्रकारों के साथ Tryout कंसोल का उपयोग करके संचालन का परीक्षण कर सकता है।

दुकान पर कार्यक्षमता।

1. View graphQL APIs labeling 'GRAPHQL' at API Listing Page

2. View operations for particular API

3. Able to download SDL schema retrieving schema

4. Provide developer console with GET and POST to invoke the API

दृश्यों का स्क्रीनशॉट

1. Create GrpahQL API page

1. Upload schema page

1. Click next and populate a form to fill details

1. Created GraphQL API overview page

1. GraphQL API operation view

1. Uploaded schema definition

1. Add/Update scopes,throttling,security

1. Store operation overview

1. Schema download

1. Developer Console

ग्राफ़िकल एपीआई का आह्वान समय

1. Authorization - API Creator can add scopes per operations at the publisher
   When the APP user invokes the graphQL API with query/mutation (read-only/ read-write) operation, API gateway will identify which operations are containing in the payload and match them according to the token scope of the user. If the payload contains multiple operations with multiple scopes, the token should have at least a union of the operation scopes.
   Eg:- Let's say when a query contains, (operation A  - scope 1, operation B -  scope 2)
   the token of the user who is going to execute the query should have both scopes (scope1 and scope2)

2. Security - API Creator can enable/disable security per operations at the publisher.
   When a query request comes with multiple operation names, security has been considered as the union of the operations security. If one operation has been enabled the security, we support security for whole request.

3. Throttling - API Creator can add throttling policy per operations at the publisher.
   When a query request comes with multiple operation names, throttle policies will apply per operation. If one operation name of the request has been throttled out according to its policy, the whole request is going to be throttled out in the case of throttled operation.

पीआर wso2/carbon-apimgt#6784 पर मिलेगा।

* At this level, we are not going to support on inspecting and analyzing queries, support API MicroGateway for GraphQL endpoints, support Graphql subscriptions with the inbound endpoints(Web socket APIs), Include an extra widget for Graphql APIs to see the count of operation invocation based on operation types, etc. Therefore, new issues have been opened to add relevant support for our future roadmap.


1. #5432

2. #5431

3. [wso2/product-microgateway#773](https://github.com/wso2/product-microgateway/issues/773)

4. [wso2/analytics-solutions#310](https://github.com/wso2/analytics-solutions/issues/310)

इस संबंध में अपने विचारों और मूल्यवान इनपुट की सराहना करें।

धन्यवाद!

हाय @ हिरण्यकविशानी ,
क्या यह समर्थन एपीआईएम के माध्यम से मौजूदा ग्राफक्यूएल एपीआई को प्रकाशित करने का परिचय देता है जैसे हम आम तौर पर मौजूदा एपीआई के लिए wso apim के माध्यम से करते हैं?

क्या इस सुविधा का परीक्षण करने के लिए कोई बीटा/अल्फा रिलीज़ भी है?

धन्यवाद !

नमस्ते @arvindkannan ,

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

यह फीचर APIM 3.0.0 के साथ उपलब्ध होगा जो अक्टूबर में रिलीज होने जा रहा है।

धन्यवाद!

समस्या को बंद करें क्योंकि यह समर्थन APIM 3.0.0 बीटा संस्करण में उपलब्ध है