Product-apim: دعم الرسم البياني

+1

+1

+1

+1

+1

+1

: +1:

مرحبًا YannickB ،

شكرا من أجل انجاح هذا. نود أن نضيف هذا إلى خارطة الطريق الخاصة بنا.

لم أستخدم GraphQL كثيرًا ، وبالتالي أواجه بعض الصعوبات في فهم النطاق الدقيق للمتطلبات. لمزيد من الوضوح ، هل يمكنك شرح القيود الدقيقة للوظيفة الحالية باستخدام مثال ربما؟ بشكل أساسي ، ما يتم الكشف عنه من خلال خادم Apollo وكيف سيتعين عليك الكشف عن ذلك من خلال API Gateway اليوم مقابل ما كان يمكن أن يكون الطريقة المثالية لعرضه من خلال بوابة API.

شكرا،
نوان.

+1

مرحبًا nuwand ،

أولاً كإخلاء للمسؤولية ، حتى لو فتحت التذكرة ، لست متأكدًا من أنني أفضل شخص لوصف كيفية عمل الميزة. فكر في كوني شخصًا يدرس لبناء بنية برمجية جيدة حقًا ، لذا بما في ذلك أشياء مثل GraphQL و API Gateway ، وبينما كنت أدرس هذا أصبح واضحًا لي أنه لا توجد بوابات API في السوق اليوم مصممة لدعم GraphQL بالكامل. ومن ثم ليس لدي أي حالة استخدام حقيقية في الإنتاج حتى الآن ، لكنني سأبذل قصارى جهدي للمساعدة.

أوافق على أن أفضل طريقة للشرح ستكون مثالاً لذلك ها هو:

لنفترض أن لديك واجهة برمجة تطبيقات توفر وظائف CRUD لكائنين ، المنتج والفاتورة.

باستخدام Rest API ، سيكون لديك نقطتا نهاية لاستخدامهما ، http://myapi.com/api/product و http://myapi.com/api/invoice ، ثم تقوم بعمليات GET / POST / PUT / DELETE عليهم.
في WSO2 ، يمكنك تكوين كل نقطة نهاية بشكل مستقل ، واحدة للمنتج والأخرى للفاتورة ، ثم تقديم تكوين محدد لكل منهما لإدارة ميزات الأمان / الخنق / تحقيق الدخل / إلخ ... التي يوفرها WSO2 بشكل مستقل.

ولكن إذا كنا نقدم واجهة برمجة تطبيقات GraphQL ، فنحن حاليًا أكثر تقييدًا بكثير. هذا يرجع إلى حقيقة أن كلا الكائنين سيكونان متاحين في نفس نقطة النهاية http://myapi.com/graphql. ولا توجد طريقة لإنشاء عدة نقاط نهاية http://myapi.com/graphql/product و http://myapi.com/graphql/invoice ، فهذا يعد مضادًا تمامًا للنمط مع أفضل ممارسات GraphQL وسيجعل معظم أدوات في نظامها الإيكولوجي للتوقف عن العمل. علاوة على ذلك ، أعتقد أن جميع عمليات 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 endpoint.

لذلك مع الحالة الحالية لبوابة WSO2 ، والتي إذا لم أكن مخطئًا ، لا تسمح إلا بالتهيئة لكل نقطة نهاية ، إذا كنت أريد على سبيل المثال تحقيق الدخل عند 0.01 سنت لكل مكالمة من أجل createInvoice من خلال تكوين http://myapi.com/graphql endpoint ، ثم سيتم أيضًا تحقيق الدخل من المكالمة إلى المنتج عند 0.01 سنت. باستخدام REST ، يمكنك فقط تكوين 0.01cent إلى http://myapi.com/api/invoice على POST وسيكون هذا كل شيء.
آمل أن يكون هذا كافيًا لك لفهم وجهة نظري ، هذا مثال بسيط ولكن يمكننا العثور على الكثير من الآخرين ، في الوضع الحالي من المستحيل استخدام ميزات Gateway مع GraphQL بسبب نقص المرونة في التكوين. وهذا ليس خطأك ، أعتقد أن جميع بوابات API الأخرى في السوق لديها نفس المشكلة.

لذا فإن الحل IMHO يسمح بإرفاق تكوين WSO2 ليس فقط بنقطة النهاية ، ولكن بوظائف GraphQL أيضًا. أعتقد أن هذا يمثل تحديًا تقنيًا ، ولكن هناك بالتأكيد حاجة لذلك في السوق لأن GraphQL حاليًا لا تعمل مع بوابات API ، أو بطريقة متدهورة للغاية.

يبدو أن هذا الاقتراح قد جذب بعض الاهتمام. للأشخاص الذين يتابعون هذه المشكلة ، أدعوك لتقديم بعض المعلومات حول حالة الاستخدام الخاصة بك وكيف يجب أن يقوم WSO2 بتصميم هذه الميزة. آمل أن أبذل قصارى جهدي لوصف الموقف ، لكنني أعتقد أنهم سيحتاجون إلى بعض الأمثلة الحقيقية لتنفيذ ذلك بشكل صحيح.

مع أطيب التحيات،
يانيك

كحل مؤقت ، سيكون من الرائع أن يكون لديك على الأقل إمكانية الاستيراد في نقاط نهاية الرسم البياني WSO2-AM ، من أجل استخدامها كدليل خدمة أثناء انتظار الدعم الكامل في بوابة API

مرحبًا YannickB ،

شكرا لك على التوضيح. سامحني ، لكنني ما زلت أحاول معرفة القيود بنقاط النهاية. اسمحوا لي أن أشرح قدرة API Manager فيما يتعلق بنقاط النهاية ، وبعد ذلك ربما يمكنك تحديد القيد.

افترض أن لديك نقطتي نهاية مثل http://myapi.com/api/invoice و http://myapi.com/api/product. لاحظ أنني أستخدم نفس المثال الذي استخدمته ، حيث يبدو أن كلا نقطتي النهاية على نفس المضيف (myapi.com). إذا كان مطلبك هو أن يكون لديك واجهة برمجة تطبيقات واحدة على API Manager لتوكيل كلتا نقطتي النهاية ، فما عليك فعله هو إنشاء مصدرين ، أحدهما POST / الفاتورة والآخر POST / product وتحديد http://myapi.com/ api / كنقطة نهاية لواجهة برمجة التطبيقات المعنية. سيمكنك هذا من الوصول إلى كلتا نقطتي النهاية أعلاه باستخدام واجهة برمجة تطبيقات واحدة. على سبيل المثال ، إذا كان مضيف البوابة هو gateway.myapi.com وكان سياق واجهة برمجة التطبيقات التي تنشئها هو / graphql وإصداره هو 1.0.0 ، فستقوم الطلبات التالية بالوكيل إلى نقطة النهاية المناسبة على النحو التالي.

انشر http://gateway.myqpi.com/graphql/1.0.0/invoice -> POST http://myqpi.com/api/invoice
انشر http://gateway.myqpi.com/graphql/1.0.0/product -> POST http://myqpi.com/api/product

لاحظ أنه ليس عليك سوى إنشاء واجهة برمجة تطبيقات واحدة (/graphql/1.0.0) لتوكيل كلتا نقطتي النهاية. أنا آسف إذا كنت أكرر شيئًا ما تعرفه بالفعل :) ، ولكن إذا كان بإمكانك تحديد القيود المفروضة على مواردنا على رسم الخرائط ، مما يجعل من المستحيل استخدام GraphQL ، فهذا سيساعدني على فهم المشكلة بشكل أفضل.

شكرا،
نوان.

نواند ، أنا أقل تقنية منك. ولكن حسب فهمي لخادم APIM / Identity ، فإننا نحدد على مستوى واجهة برمجة التطبيقات إدارة واجهة برمجة التطبيقات (الأمان ، الاختناق ، ...). GraphQL هي نوع من اللغات "الفائقة" التي تجمع بين واجهات برمجة التطبيقات عبر لغة "meta". ما قد يثير اهتمامي هو فهم كيفية مطابقة مفاهيم GraphQL ومفاهيم WS02 APIM. وإذا كان سيتم دمج كلا المفهومين. في الحال ، يمكنك التفكير في مورد GraphQL أيضًا الذي يدير كل شيء بنفسه .... ولكن قيمة WS02 محدودة إذا كان من الممكن الوصول إلى جميع خدماتي القديمة عبر خادم Graphql.

+1

مع GraphQL ، لا توجد سوى نقطة نهاية واحدة ، لذلك لا يوجد شيء مثل myapi.com/graphql/invoice و graphql / product ، والنقطة النهائية هي "myapi.com/graphql" فقط ، ولا شيء بعد ذلك. هو حرفيا نفس عنوان URL لكل استعلام وطفرة ، مع تحديد العمليات داخل نص الطلب.

ستتطلب بعض ميزات إدارة واجهة برمجة التطبيقات بعد ذلك استبطانًا لجسم الطلب ، ومعرفة مخطط الرسم البياني ، وما إلى ذلك. لنفترض أن هذا _ غير ممكن على المدى القصير: يجب أن يصبح WSO2 خادمًا / بوابة GraphQL في حد ذاته (أو يدمج واحدًا).

بدلاً من ذلك ، يجب أن نركز على ميزات إدارة واجهة برمجة التطبيقات الممكنة. أعتقد أننا بحاجة إلى التعاون بين WSO2 وخادم / بوابة GraphQL الفعلية ، على سبيل المثال عن طريق تعيين الرؤوس. على سبيل المثال تحقيق الدخل: يمكن لخادم GraphQL حساب مدى تعقيد الاستعلام ، وإضافة هذه المعلومات كرأس HTTP للاستجابة ، حيث يترجم WSO2 هذه القيمة إلى سعر. وبالمثل بالنسبة للمراقبة ، يمكن لخادم GraphQL "تحويل" الاستعلام على شكل JSON إلى (قائمة) نقاط نهاية زائفة تشبه الراحة ، والتي يقرأها WSO2 من رأس الاستجابة لتحديث معلومات المراقبة. يمكن فعل الشيء نفسه للأمان ، ربما على مرحلتين: أولاً اطلب من خادم GraphQL تحويل الاستعلام إلى نقاط نهاية شبيهة بالراحة ، يقرر WSO2 أن يمرر أو لا ، يعيد توجيه الاستعلام إلى نقطة النهاية الفعلية.

أنا جديد تمامًا على WSO2 ولم أقرأ معظم الوثائق ، لذلك ربما تكون هذه الميزات موجودة بالفعل في WSO2 (بشكل أكثر تحديدًا: لأي وظيفة من وظائف WSO2 مشتقة عادةً من URI المحدد لنقطة نهاية REST ، ما إذا كانت نفس الوظيفة يمكنها يمكن اشتقاقها بطريقة بديلة (مثل قيمة الرأس أو بعض واجهة برمجة التطبيقات الأخرى لـ WSO2 نفسها)). من المحتمل أن يحتاج خادم GraphQL إلى التعديل لدعم هذه الميزات الخاصة بـ WSO2. السؤال هو: ما هي الفاكهة المعلقة المنخفضة التي يمكننا أن نبدأ بها؟

(بالطبع أود أن أرى WSO2 يلتزم بشدة بـ GraphQL ... لكننا نحتاج إلى البدء في شيء ما ، أليس كذلك؟)

ردود فعل رائعة ، أشعر بنفس الشيء ؛)

يوم 6 نوفمبر. 2018 om 12:06 schreef 4th44 [email protected] :

مع GraphQL ، لا يوجد سوى نقطة نهاية واحدة ، لذلك لا يوجد مثل هذا
الشيء مثل myapi.com/graphql/invoice و Graphql / product ، فإن النقطة النهائية هي
فقط "myapi.com/graphql" ، ولا شيء بعد ذلك. هو حرفيا
نفس عنوان URL لكل استعلام وطفرة ، مع تحديد العمليات بالداخل
نص الطلب.

ستتطلب بعض ميزات إدارة واجهة برمجة التطبيقات (api) بعد ذلك استبطانًا لملف
نص الطلب ، ومعرفة مخطط الرسم البياني ، وما إلى ذلك. لنفترض أن هذا
ليس مجديًا على المدى القصير: يجب أن يصبح WSO2 تقريبًا GraphQL
الخادم / البوابة في حد ذاتها (أو دمج واحد).

بدلاً من ذلك ، يجب أن نركز على ميزات إدارة واجهة برمجة التطبيقات الممكنة.
أعتقد أننا بحاجة إلى التعاون بين WSO2 و GraphQL الفعلي
الخادم / البوابة ، على سبيل المثال عن طريق تعيين الرؤوس. على سبيل المثال تسييل: ملف
يمكن لخادم GraphQL حساب مدى تعقيد الاستعلام ، أضف هذا
المعلومات كرأس HTTP للاستجابة ، حيث يترجم WSO2 هذا
القيمة في السعر. وبالمثل بالنسبة للمراقبة ، يمكن لخادم GraphQL القيام بذلك
"تحويل" الاستعلام على شكل JSON إلى (قائمة) يشبه الراحة
نقطة (نقاط) النهاية الزائفة ، التي يقرأها WSO2 من رأس الاستجابة لتحديث ملف
معلومات المراقبة. يمكن فعل الشيء نفسه للأمان ، ربما في 2
المراحل: أولاً ، اطلب من خادم GraphQL تحويل الاستعلام إلى ما يشبه الراحة
نقاط النهاية ، يقرر WSO2 التمرير أم لا ، وإعادة توجيه الاستعلام إلى الفعلي
نقطة النهاية.

أنا جديد تمامًا على WSO2 ولم أقرأ معظم الوثائق ، لذلك
ربما تكون هذه الميزات موجودة بالفعل في WSO2 (بشكل أكثر تحديدًا: لأي
وظيفة WSO2 المشتقة عادةً من نقطة نهاية REST الدقيقة
URI ، ما إذا كان يمكن اشتقاق نفس الوظيفة بطريقة بديلة
(على سبيل المثال ، قيمة رأس أو بعض واجهة برمجة التطبيقات الأخرى لـ WSO2 نفسها)). من المحتمل أن
يحتاج خادم GraphQL إلى التعديل لدعم هذه الخاصة بـ WSO2
الميزات. السؤال هو: ما هي الفاكهة المعلقة المنخفضة التي يمكننا أن نبدأ بها؟

(بالطبع أود أن أرى WSO2 يلتزم بشدة بـ GraphQL ...
لكن علينا أن نبدأ في مكان ما ، أليس كذلك؟)

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/wso2/product-apim/issues/3184#issuecomment-436215537 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/Ad4tuNmWvNcpkc1Nk5y46DljcQeM9RPwks5usW0kgaJpZM4TLf2Q
.

-
بارت فان فليربيرغي

مرحبا،
فيما يلي مقتطف من وثائق خادم أبولو:
_ "إذا كنت تستخدم واجهة برمجة تطبيقات REST تحتوي على ترخيص مضمّن ، مثل رأس HTTP ، فلديك خيار واحد آخر. بدلاً من القيام بأي عمل مصادقة أو تفويض في طبقة GraphQL (في وحدات التحليل / النماذج) ، فمن الممكن لتمرير العناوين أو ملفات تعريف الارتباط ببساطة إلى نقطة نهاية REST والسماح لها بتنفيذ العمل. "_
إذا كان مفتاح واجهة برمجة التطبيقات هو نفسه بالنسبة لجميع نقاط النهاية التي تتضمنها استعلامات الرسم البياني الخاصة بك ، فيبدو أنه يمكن أن يؤدي الغرض.
أي أفكار حول هذا "الحل البديل" (ضع خادم Apollo أمام API-M)؟

تحليل الاحتياجات

• تم تطوير GraphQL بواسطة Facebook وهو بديل لـ REST. إنها لغة استعلام لواجهات برمجة التطبيقات حيث يمكن لمستخدم معين تحديد البيانات المطلوبة بالضبط من واجهة برمجة التطبيقات.
• نحن نعلم أنه يمكننا استخدام تعريف Swagger (مواصفات Open API) لتصميم REST API. ولكن في GraphQL ، يمكننا استخدام لغة تعريف المخطط (SDL) لكتابة مخطط واجهة برمجة تطبيقات GraphQL.
• يعني استدعاء واجهة برمجة تطبيقات GraphQL ببساطة جلب البيانات باستخدام استعلامات GraphQL وكتابة البيانات باستخدام طفرات GraphQL.
• هنا يتمثل مطلبنا في تقديم الدعم من WSO2 APIM لإنشاء ونشر واجهة برمجة تطبيقات GraphQL واستدعاءها عبر https / http.

النهج المقترح

• عند نشر واجهة برمجة تطبيقات GraphQL ، نطلب من المستخدم (الناشر) تحميل ملف المخطط الذي يتكون من التعريف. ثم يمكن للمستخدم ملء التفاصيل حول واجهة برمجة التطبيقات مثل الاسم والإصدار والسياق وما إلى ذلك. ولكن لن يُطلب من المستخدم إنشاء موارد لطرق GET و POST عند إنشاء واجهة برمجة التطبيقات.
  

• بعد ذلك ، في علامة التبويب " تنفيذ " ، إذا اختار المستخدم ،

  • إدارة API

    • يجب تعيين نوع نقطة النهاية على نقطة نهاية HTTP / REST تلقائيًا. (يجب ألا يكون لدى المستخدم القدرة على تغيير هذا)
    • يجب أن يكون لدى المستخدم القدرة على تغيير نقطة النهاية (الإنتاج ووضع الحماية) كالمعتاد.
    • يجب أن تظل الحقول الأخرى كما هي.
      

  • النموذج الأولي API

    • في طريقة التنفيذ المضمنة ، يجب إنشاء طريقتين GET و POST تلقائيًا وعرضهما كما هو معروض في لقطة الشاشة التالية.
      

• إذا اخترت خيار إدارة واجهة برمجة التطبيقات ، فيجب عليك ضبط الإعدادات في علامة التبويب إدارة .

  • هنا يجب اتباع نفس الإجراء.
  • بشكل خاص كما في أسلوب Inline prototype ، يجب إنشاء طريقتين GET و POST تلقائيًا وعرضهما كما في لقطة الشاشة التالية.
    

• بعد نشر API أو وضع نماذج أولية لها

  • يجب تسمية واجهة برمجة التطبيقات على أنها واجهة برمجة تطبيقات GraphQL في متجر واجهة برمجة التطبيقات.
  • يجب أن يكون لدى العميل القدرة على تنزيل ملف المخطط لواجهة برمجة التطبيقات من خلال متجر واجهة برمجة التطبيقات.

تبدو رائعة

wasuradananjith هل يمكنك أيضًا نشر كيف تبدو واجهة برمجة تطبيقات GraphQL في المتجر؟ هل الاستعلام متاح في بوابة API ، ربما مع المخطط؟

تدعم Apollo على الأقل استخدام GET لطلب بيانات GraphQL.

أهلا بكم،

يرجى العثور على المعلومات والعلاقات العامة لدعم Graphql المتعلقة بإصدار WSO2 APIM 3.0.0. نظرًا لأننا سنقوم بإصدار WSO2 APIM 3.0.0 ضمن واجهة مستخدم جديدة قائمة على React ، تمت إضافة لقطات شاشة لواجهة مستخدم جديدة في ما يلي.

ناشر API
وصف:
عندما يقوم منشئ واجهة برمجة التطبيقات بتحميل مخطط GraphQL إلى ناشر واجهة برمجة التطبيقات ، سيتم إدراج عمليات الاستعلام والتحول في بوابة الناشر. ثم سيسمح بتحديد النطاقات وسياسات الاختناق وتمكين / تعطيل الأمان ضد العمليات.

الوظائف في الناشر.

1. أنشئ واجهات برمجة تطبيقات GraphQL عن طريق استيراد مخطط GraphQL SDL
2. تحقق من صحة المخطط واستخرج عملياته من تعريف المخطط
3. استرداد / استيراد / تنزيل مخطط SDL من الناشر.
4. يظهر العمليات بدلا من الموارد
5. إضافة / تحديث الاختناق والنطاقات والأمان ضد العمليات
6. اعرض واجهات برمجة تطبيقات GraphQL التي تحمل علامة "GRAPHQL" في صفحة قائمة واجهة برمجة التطبيقات

متجر API
بمجرد نشر مستخدم الناشر لواجهة برمجة التطبيقات (API) ، يتم ملء جميع العمليات في مخطط SDL في بوابة المطور ويتاح أيضًا تنزيل ملف المخطط. يمكن للمطور اختبار العمليات باستخدام وحدة تحكم Tryout مع أنواع طلبات GET و POST.

الوظائف في المتجر.

1. اعرض واجهات برمجة تطبيقات GraphQL التي تحمل علامة "GRAPHQL" في صفحة قائمة واجهة برمجة التطبيقات
2. عرض عمليات API معينة
3. قادر على تنزيل مخطط استرداد مخطط SDL
4. توفير وحدة تحكم المطور مع GET و POST لاستدعاء API

لقطات من وجهات النظر

1. إنشاء صفحة GrpahQL API
   

1. تحميل صفحة المخطط
   

2. انقر فوق التالي وقم بتعبئة نموذج لملء التفاصيل
   

3. صفحة نظرة عامة على GraphQL API التي تم إنشاؤها
   

4. عرض عملية واجهة برمجة تطبيقات GraphQL
   

5. تعريف المخطط الذي تم تحميله
   

6. إضافة / تحديث النطاقات والاختناق والأمان
   

7. نظرة عامة على تشغيل المتجر
   

8. تنزيل المخطط
   

9. وحدة تحكم المطور
   

وقت استدعاء Graphql API

1. التفويض - يمكن لـ API Creator إضافة نطاقات لكل عملية لدى الناشر
   عندما يستدعي مستخدم APP واجهة برمجة تطبيقات GraphQL مع عملية استعلام / طفرة (للقراءة فقط / للقراءة والكتابة) ، ستحدد بوابة API العمليات التي تحتويها الحمولة وتطابقها وفقًا لنطاق الرمز المميز للمستخدم. إذا كانت الحمولة تحتوي على عمليات متعددة ذات نطاقات متعددة ، فيجب أن يحتوي الرمز المميز على الأقل على اتحاد نطاقات العملية.
   على سبيل المثال: - لنفترض عندما يحتوي الاستعلام على ، (العملية أ - النطاق 1 ، العملية ب - النطاق 2)
   يجب أن يحتوي الرمز المميز للمستخدم الذي سينفذ الاستعلام على كلا النطاقين (النطاق 1 والنطاق 2)

2. الأمان - يمكن لـ API Creator تمكين / تعطيل الأمان لكل عملية لدى الناشر.
   عندما يأتي طلب استعلام بأسماء عمليات متعددة ، فقد تم اعتبار الأمان بمثابة اتحاد لأمن العمليات. إذا تم تمكين الأمان لعملية واحدة ، فإننا ندعم الأمان للطلب بأكمله.

3. Throttling - يمكن لـ API Creator إضافة سياسة الاختناق لكل عملية عند الناشر.
   عندما يأتي طلب استعلام بأسماء عمليات متعددة ، سيتم تطبيق سياسات الخانق لكل عملية. إذا تم اختناق اسم عملية واحد للطلب وفقًا لسياستها ، فسيتم اختناق الطلب بالكامل في حالة العملية المخنوقة.

يمكن العثور على العلاقات العامة على https://github.com/wso2/carbon-apimgt/pull/6784.

• في هذا المستوى ، لن ندعم فحص الاستعلامات وتحليلها ، ودعم API MicroGateway لنقاط نهاية GraphQL ، ودعم اشتراكات Graphql مع نقاط النهاية الواردة (واجهات برمجة تطبيقات مقبس الويب) ، وتضمين عنصر واجهة مستخدم إضافي لواجهات برمجة تطبيقات Graphql لمعرفة عدد استدعاء العملية بناءً على أنواع العمليات ، وما إلى ذلك. لذلك ، تم فتح قضايا جديدة لإضافة الدعم المناسب لخارطة الطريق المستقبلية.

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

نقدر أفكارك ومدخلاتك القيمة بخصوص هذا.

شكرا!

أهلا بكم،

يرجى العثور على المعلومات والعلاقات العامة لدعم Graphql المتعلقة بإصدار WSO2 APIM 3.0.0. نظرًا لأننا سنقوم بإصدار WSO2 APIM 3.0.0 ضمن واجهة مستخدم جديدة قائمة على React ، تمت إضافة لقطات شاشة لواجهة مستخدم جديدة في ما يلي.

ناشر API
وصف:
عندما يقوم منشئ واجهة برمجة التطبيقات بتحميل مخطط GraphQL إلى ناشر واجهة برمجة التطبيقات ، سيتم إدراج عمليات الاستعلام والتحول في بوابة الناشر. ثم سيسمح بتحديد النطاقات وسياسات الاختناق وتمكين / تعطيل الأمان ضد العمليات.

الوظائف في الناشر.

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

متجر API
بمجرد نشر مستخدم الناشر لواجهة برمجة التطبيقات (API) ، يتم ملء جميع العمليات في مخطط SDL في بوابة المطور ويتاح أيضًا تنزيل ملف المخطط. يمكن للمطور اختبار العمليات باستخدام وحدة تحكم Tryout مع أنواع طلبات GET و POST.

الوظائف في المتجر.

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

وقت استدعاء Graphql API

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)

نقدر أفكارك ومدخلاتك القيمة بخصوص هذا.

شكرا!

مرحبًا HiranyaKavishani ،
هل يقدم هذا الدعم إمكانية نشر واجهة برمجة تطبيقات GraphQL الحالية عبر APIM مثلما نفعل عادةً لواجهة برمجة التطبيقات الحالية عبر wso apim؟

هل هناك أيضًا أي إصدار تجريبي / ألفا لاختبار الميزة؟

شكرا !

مرحبًا arvindkannan ،

بالنسبة لواجهات برمجة تطبيقات Graphql الحالية ، من الضروري إعادة إنشاء واجهات برمجة التطبيقات وإعادة النشر نظرًا لأن الرسم البياني يحتوي على دعم مختلف عند مقارنته بواجهات برمجة التطبيقات الأخرى. ولكن في حالة القيام بذلك ، يجب التأكد من أن الرموز المميزة الحالية وعناوين URL الحالية لن تتغير مع هذا لأنها ستتأثر بالعملاء الحاليين.

ستتوفر الميزة مع APIM 3.0.0 الذي سيصدر في أكتوبر.

شكرا!

أغلق المشكلة لأن هذا الدعم متوفر في إصدار APIM 3.0.0 Beta