""اختياري" في مخطط واجهة برمجة التطبيقات لا يعني اختياريًا في بيئة الإنتاج. هذا شيء يجب أن يتعلمه كل مطور Web3.**
أثناء العمل على تدفق تفويض Newton Protocol، لفت انتباهي خيار تصميم واحد: في مخطط الطلب الأساسي، تم وسم حقل `intent_signature` في RPC `newt_createTask` على أنه اختياري.
قد يكون ذلك مُربِكًا في البداية.
إذا كان اختياريًا، فلماذا تفشل بعض الطلبات بدونه؟
الإجابة تكمن في كيفية فصل Newton بين **البنية التحتية العامة** و**متطلبات السياسة الخاصة**.
تم تصميم RPC الأساسي لدعم مجموعة متنوعة من نماذج التفويض. بعض السياسات لا تتطلب إلا بيانات معاملة أساسية، بينما يقوم البعض الآخر بالتحقق من نية المستخدم عبر **توقيع EIP-712**. نقطة النهاية المشتركة لا تتطلب ذلك، لكن إذا أشارت سياسة إلى `intent_signature`، أو إذا اعتمدت عملية تفويض معتمدّة على PolicyClient أو تعتمد على الهوية عليه، عندها يصبح التوقيع مطلوبًا.
هذا خيار معماري مهم.
بدلًا من إنشاء واجهات برمجة منفصلة لكل نموذج تفويض، يقدم Newton واجهة واحدة مرنة يمكن تكييفها لتناسب احتياجات أمان مختلفة. هذا يجعل البروتوكول قابلًا للتوسعة ويسمح للمطورين ببناء أي شيء بدءًا من الأتمتة البسيطة وصولًا إلى مسارات مالية منظمة بشدة على نفس البنية التحتية.
لكن هذه المرونة تتحمل مسؤولية على عاتق المُدمجين.
قد يقوم الواجهة الأمامية بالتحقق من صحة المدخلات مقابل المخطط الأساسي، لكنها قد لا تمتلك كل الحقول التي تتطلبها السياسة المحددة. في كثير من الحالات، سيرفض Gateway الطلب قبل حتى تقييم سياسة Rego، لأن التواقيع غير الصالحة أو الفارغة (مثل `0x`) لا تتوافق مع تنسيق توقيع EIP-712 المتوقع.
ما يعنيه ذلك هو أن المطورين لا ينبغي أن يعتبروا التحقق من صحة المخطط هو طبقة التحقق الأخيرة.
يجب أن تفهم عملية التكامل الجيدة:
✅ سياسة التفويض المستخدمة.
✅ هل تتطلب هذه السياسة نية مُوقّعة.
✅ هل يضيف التدفق المعتمد على هوية أي متطلبات توقيع إضافية.
✅ اجعل المستخدم يوقّع قبل إرسال الطلب
#newtonprocol @NewtonProtocol $NEWT