الواجهة البرمجية والـ Webhooks: سلسلة الثقة نفسها، خارج التطبيق

الرقم الموثوق داخل تطبيق ما وغير القابل للتحقّق لحظة خروجه منه ليس موثوقاً فعلياً، بل يبدو موثوقاً فقط بينما يراقبه أحدهم. السطح البرمجي في Rexfin مبني على قاعدة واحدة: كل ما يستطيع رقم إثباته على الشاشة، يُثبته بالطريقة نفسها تماماً بمجرد سحبه عبر الواجهة البرمجية، أو webhook، أو تصدير مُهيكَل. لا شيء يُغسَل ليبدو أنظف في طريقه للخارج.

ما يحمله كل رقم في طريقه للخارج

كل قيمة تصدرها الواجهة البرمجية أو webhook تأتي مغلَّفة بالغلاف نفسه: عملتها ومقياس وحدتها، وما إذا كانت رقماً فعلياً أم مُصاغاً بالنمذجة، والأهم، مقبض استشهاد إن وفقط إن كانت فعلية. الإسقاط المُصاغ بالنمذجة لا يصدر أبداً مصحوباً باستشهاد، لأنه لا يكتسبه داخل التطبيق أصلاً. وإن لم يكن رمز وصول المستدعي مُخوَّلاً بالوصول إلى مستند المصدر الأساسي، فإن الاستشهاد ببساطة لا يُحلّ: تُعاد استجابة «مقيَّد» تفشل بأمان، لا نسخة مبتورة من الشيء الحقيقي. المخطط نفسه يجعل التمييز بين الفعلي والمُصاغ بالنمذجة أمراً لا مفرّ منه: لا يمكن لمطوّر يدمج النظام أن يكتب بالخطأ كوداً يعامل توقّعاً وكأنه رقم إيداع فعلي، لأن الحقل الذي كان سيحمل الإثبات ببساطة غير موجود.

واجهة REST موثَّقة ومُصنَّفة بإصدارات

طبقة REST هي سطح قراءة موصوف بـ OpenAPI ومُصنَّف بإصدارات: القوائم المالية، والخلايا الفردية، والسيناريوهات المُسمّاة، وحكم المُتحقِّق الحالي لنموذج ما، والفرق بين نسخة والنسخة السابقة. وهي مخصَّصة للقراءة في الغالب بتصميم مقصود: لا شيء في هذا السطح يتيح لمستدعٍ خارجي كتابة خلية أو محرّك مرة أخرى إلى نموذجك، لأن هذه الصلاحية تبقى داخل التطبيق حيث يتتبّع مسار التدقيق من غيّر ماذا. يمرّ الوصول عبر OAuth/OIDC ورموز مُخوَّلة بنطاق محدَّد، ونطاق كل رمز الفعلي مُقيَّد بالأضيق بين ما مُنِح له الرمز وما تسمح به صلاحيات الوصول الخاصة بالشخص الذي طلبه، لا يمكن لرمز أبداً أن يرى أكثر مما يستطيع الإنسان الذي أصدره أن يراه، وفقدان الوصول في منتصف الجلسة يقطع الرمز فوراً لا عند تجديده التالي.

Webhooks: تُخبَر لا تُستَقصى

بدل قرع الواجهة البرمجية على جدول زمني، يشترك المستقبِل في الأحداث التي تهمّه (إقفال فترة، أو اكتمال حزمة عرض لمجلس الإدارة، أو نشر نسخة، أو نجاح أو فشل بوابة المُتحقِّق في محاولة تصدير). كل إرسال موقَّع، بحيث يستطيع المستقبِل التأكّد من أنه صادر فعلاً عن Rexfin، ويُسلَّم مرة واحدة على الأقل بمعرّف حدث ثابت، بحيث يمكن اكتشاف التكرار بدل معالجته بصمت مرتين. أي نقطة اشتراك متوقّفة تُعاد محاولة الإرسال إليها بتأخير تصاعدي، لا بقرع لا نهائي، وتبقى الإرسالات السابقة مُدرَجة وقابلة لإعادة التشغيل إن احتجت لسحب واحدة مجدداً. أما webhook من نوع verifier.failed، فهو تحديداً الإشارة نفسها التي يعرضها التطبيق داخلياً بأن «هذا النموذج لا يمكن الوثوق به للتصدير»، منقولة إلى أي مسار معالجة لاحق يحتاج إلى معرفتها، دون أن يضطر أحد للتحقّق من الواجهة أولاً.

تصديرات مُهيكَلة لا تغادر إلا حين يتّزن النموذج

إلى جانب حزمة العرض القابلة للقراءة البشرية، يمكن لـ Rexfin إنتاج تصديرات قابلة للاستهلاك الآلي (iXBRL مُوسَمة وفق التصنيف نفسه الذي تستخدمه القوائم، إضافة إلى JSON وCSV مسطَّحَين) لاستيعابها لاحقاً من قِبل جهة تنظيمية، أو نظام إيداع بورصة، أو مسار تجميع. هذه التصديرات مُقيَّدة تماماً كما تُقيَّد حزمة العرض: نموذج غير متّزن وغير مسوّى لا يمكنه إنتاج واحدة. فالتصدير المُهيكَل لنموذج لا يتّزن هو تحديداً الفشل الذي وُجد هذا الانضباط كلّه لمنعه، لذا تنطبق البوابة هنا أيضاً، لا على المستند الذي يقرأه إنسان فحسب.

لمن هذا مُصمَّم

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

للجانب الموجَّه للوكلاء من هذا السطح نفسه، اطّلع على كيف يوسّع وصول MCP القواعد نفسها إلى مساعدي الذكاء الاصطناعي، أو ابدأ من محور جولة المنتج للصورة الكاملة.