يبدو أن هناك إمكانية لتحسينات في كيفية عرض تعيينات الوسوم للمواضيع عبر واجهة برمجة التطبيقات. وتحديدًا، القدرة على الاستعلام عن الوسوم المضافة حديثًا للمواضيع. حالة الاستخدام الخاصة بي هي استخدام الوسوم في Discourse للإشارة إلى أنه يجب تصدير بعض المواضيع إلى نظام آخر (مثل مدير المهام)، وأخطط لاستخدام Integromat للقيام بذلك. لكن هذا يمكن أن ينطبق بسهولة على أي نظام يستعلم عن واجهة برمجة التطبيقات لتحديد ما إذا تم إضافة وسم مثل “إنشاء مهمة” إلى موضوع ما، ثم التصرف بناءً على هذه المعلومات.
فهمي هو أن واجهة برمجة التطبيقات الحالية لا تسمح بذلك بسهولة. هناك حل بديل باستخدام webhooks، لكن ما لم أكن مخطئًا، فإن استدعاء واجهة برمجة التطبيقات المباشر سيكون أنظف وأبسط.
شكرًا على النظر في هذا الأمر! آمل أنني وضعت هذا في المكان الصحيح.
إضافة وسم في موضوع سيؤدي إلى تفعيل فئة topic الخاصة بـ webhook، والتي يمكنك الاستماع إليها لمراقبة أي وسوم جديدة تمت إضافتها في مواضيعك. يمكنك حتى تصفيته لوسم محدد في واجهة مستخدم Discourse، للحفاظ على عدد الأحداث منخفضًا.
شكرًا لك على الرد السريع! إذن، هل «الحل البديل» الذي تقترحه Integromat هو حقًا الطريقة المقصودة للتعامل مع هذا الأمر؟
للأسف، لستُ خبيرًا في الفرق بين واجهة برمجة التطبيقات (API) والويب هوك وما إلى ذلك، لكنني أفكر تحديدًا في التكامل الذي توفره Fibery مع Discourse. فهي في الواقع تنسخ محتوى Discourse بالكامل، ولكن في نظام يسمح بالربط التعسفي للبيانات (مثل المواضيع، المستخدمين، إلخ) لإدارة المشاريع والتغذية الراجعة على مستوى أعلى. كما أفهم الأمر، فهم يستخدمون واجهة برمجة التطبيقات (API) لهذا التكامل:
لذا، إذا أرادوا هم دعم الوسوم في تكاملهم (وهو ما لا يفعلونه حاليًا)، بما في ذلك اكتشاف إضافة/إزالة الوسوم، فهل سيكون ذلك ممكنًا باستخدام واجهة برمجة التطبيقات (API) الحالية؟ وإذا لم يكن كذلك، فهل يشير ذلك إلى فائدة لم تُرَ بعد لإضافة عمق أكبر لدعم الوسوم في واجهة برمجة التطبيقات؟
مرة أخرى، أدرك أنني قد أطرح أسئلة بديهية بسبب جهلي. ربما يكون من الصعب أو غير المعقول تقنيًا كشف هذه المعلومة عبر واجهة برمجة التطبيقات (API)، أو ببساطة لا يكون منطقيًا لسبب ما. لكنني آمل أن يكون الأمر سهلًا بما يكفي للتوضيح.
تسمح مكالمة واجهة برمجة التطبيقات (API) لخدمة خارجية باستدعاء منصة Discourse في أي وقت لاستخراج البيانات منها.
ومع ذلك، إذا أرادت تلك الخدمة التفاعل مع الأحداث في منصة Discourse، فستحتاج إلى الاستعلام الدوري عن التغييرات، وهو أمر إما مهدر أو غير عملي إذا كانت هناك العديد من “الأشياء” التي يجب مراقبتها أو الاستعلام عنها.
تسمح خطافات الويب (Webhooks) لمنصة Discourse بإشعار هذه الخدمة الخارجية بلطف في كل مرة يحدث فيها حدث جديد، بحيث يمكن لهذه الخدمة الخارجية القيام بـ أمرها فقط عندما يكون هناك شيء يجب فعله. يمكن للخدمة الاعتماد على معلومات حمولة خطاف الويب (webhook payload)، إذا كانت كافية، أو استخدامها لتفعيل مكالمات إضافية لواجهة برمجة التطبيقات (API) لتنفيذ المهمة المطلوبة. وبالتالي، فإن نظام واجهة برمجة التطبيقات (API) ونظام خطافات الويب (webhooks) مكملان لبعضهما البعض.
ممتاز، هذا مفيد جدًا. إذن، لنفترض أنك تقوم بعكس محتوى Discourse إلى نظام خارجي (Fibery). إذا فهمتُ بشكل صحيح، فمن المنطقي استخدام واجهة برمجة التطبيقات (API) لجمع بيانات المواضيع وغيرها في البداية. لكن إذا أردت الحفاظ على تحديث هذه البيانات بمرور الوقت، مثل تغييرات الفئات أو الوسوم، فستحتاج إلى استخدام Webhooks لمتابعة هذه التغييرات، أليس كذلك؟ إذا كان الأمر كذلك، فماذا عن الحصول على بيانات مواضيع جديدة تمامًا؟ هل يتم ذلك عبر واجهة برمجة التطبيقات أم عبر Webhook؟ ربما يمكن طرح السؤال بشكل آخر: هل من المنطقي استخدام واجهة برمجة التطبيقات لسحب البيانات مرة واحدة فقط لملء النسخة المنعكسة، ثم الاعتماد على Webhooks بشكل مستمر لتحديثها في جميع الجوانب؟ أم أن الأمر مزيج من الاثنين، وإذا كان كذلك، كيف يعمل هذا المزيج؟
أحب أن أستطيع إغلاق الحلقة في هذا الموضوع وأعرف أنني أفهم تمامًا كيف يجب أن يعمل هذا. أنا أعمل مع فريق Fibery على أمل أن يقوموا بتطبيق هذا أيضًا. لذا، إذا توفرت لك الفرصة للإجابة على أسئلتي المتبقية، فسأكون ممتنًا جدًا.
