Skip to main content
هذا الدليل يوضح العملية الكاملة لـ Ace Data Cloud X402 من خلال طلب API بسيط. الهدف ليس كتابة كود معقد أولاً، بل فهم: لماذا سيعيد الطلب الأول 402، وما هو موجود في accepts، وكيف تجعل PAYMENT-SIGNATURE نفس طلب API يتحول إلى طلب مدفوع.

التحضيرات

تحتاج إلى تحضير: لا تحتاج X402 لاستدعاء Ace Data Cloud API إلى رمز API. الطلب الأول من SDK لا يحمل Authorization، وستعيد البوابة 402 Payment Required ومتطلبات الدفع؛ بعد التوقيع، سيعيد SDK المحاولة تلقائيًا.

تثبيت SDK

عنوان المصدر والحزمة: TypeScript:
Python:
إذا كنت ترغب في استخدام Solana، ستحتاج أيضًا إلى تثبيت الاعتماديات المناسبة:
اعتماديات Solana في إصدار Python تم تضمينها بالفعل في acedatacloud-x402. تثبيت وفحص الإخراج في بيئة نظيفة مؤقتة:
تفسير النتائج:
  • حزم npm وحزم PyPI هي حزم منشورة حقيقية، وليست أسماء موضوعة في الوثائق.
  • acedatacloud-x402[cli] ستقوم بتثبيت CLI، ويمكن استخدام الأمر الفرعي approve-permit2 لمشاهدات upto لتفويض Permit2.

الطلب الأول سيعيد 402

يمكنك أولاً استخدام curl لرؤية ما تعيده الطلبات غير المدفوعة. المثال أدناه لن ينتج عنه خصم، لأنه لا يحمل PAYMENT-SIGNATURE:
سيحتوي جسم الاستجابة على مصفوفة accepts، الهيكل الشائع كما يلي:
سيتم أيضًا وضع نفس محتوى التحدي في شكل base64 في رأس الاستجابة PAYMENT-REQUIRED، مما يسهل على العميل قراءة متطلبات الدفع دون تحليل الجسم. ملخص الإخراج لطلب API غير المدفوع في الإنتاج كما يلي:
تفسير النتائج:
  • الطلب الأول لم يحمل Authorization أو PAYMENT-SIGNATURE، لذا أعاد HTTP 402، ولن ينتج عنه خصم.
  • accepts هو المصدر الوحيد الموثوق للتوقيع في هذا الطلب، ويحتوي على الشبكات الاختيارية، المخطط، الحد الأقصى للمبلغ، عنوان الدفع وعنوان الأصول.
  • network هو تعريف CAIP-2، ويجب على العميل مطابقة الشبكة وفقًا لسلسلة CAIP-2.
  • الحد الأقصى لمبلغ طلب الدردشة الأدنى لـ gpt-4o-mini هو 95215 وحدة USDC الذرية، أي ما يعادل 0.095215 USDC.
  • يجب قراءة استجابة 402 في كل طلب، ولا يجب ترميز المبلغ النموذجي في كود العمل.
معاني الحقول:

إكمال الدفع وإعادة المحاولة باستخدام SDK

إليك مثال TypeScript الأدنى. يحدد network: 'skale'، وسيختار المعالج متطلبات الدفع لـ SKALE من استجابة 402 هذه؛ المبلغ الفعلي وعنوان الدفع لا يزالان يعتمدون على accepts.
نتيجة تشغيل البرنامج باستخدام SDK من نفس السلسلة:
تفسير النتيجة:
  • content ADC_TS_SDK_X402_OK هو سلسلة ثابتة تعود بها النموذج وفقًا للكلمات الدلالية، مما يدل على أن الدفع قد تم إعادة المحاولة بعد أن دخل الطلب فعليًا إلى واجهة برمجة التطبيقات للنموذج.
  • payer هو عنوان محفظة التوقيع المحلية، لم يتم إرسال المفتاح الخاص إلى Ace Data Cloud.
  • أكمل SDK تحليل 402، وتوقيع PAYMENT-SIGNATURE وإعادة محاولة الطلب الأصلي؛ لا تزال الشيفرة التجارية مكتوبة بطريقة استدعاء SDK العادية.
حدثت أربع خطوات وراء هذا الكود:
  1. أرسل SDK طلب API عادي مرة واحدة، دون Authorization.
  2. أعاد Gateway 402 Payment Required و accepts.
  3. اختار createX402PaymentHandler متطلبات الدفع لـ network = 'skale' ووقع PAYMENT-SIGNATURE.
  4. أعاد SDK محاولة بنفس جسم الطلب، بعد أن تحقق Gateway من Facilitator وأجرى التسوية، تم السماح بالوصول إلى واجهة برمجة التطبيقات المستهدفة.

عرض قدرات Facilitator

لا تعتمد واجهة برمجة التطبيقات X402 على دليل الموارد. يستدعي العميل واجهات برمجة التطبيقات المعروفة مباشرة، ويستخدم 402 Payment Required و accepts التي تم إرجاعها في الوقت الفعلي كمرجع وحيد للسعر والتوقيع. تقع بيانات قدرة Facilitator في:
تصف فقط /supported، /verify، /settle والشبكات المدفوعة الحالية، ولا تسرد موارد واجهة برمجة التطبيقات. عنوان Facilitator الإنتاجي لـ Ace Data Cloud هو:
يمكنك عرض الشبكات والمخططات التي يدعمها:
ستدرج kinds المدعومة من قبل Facilitator الشبكات والمخططات. لا يزال يتم الاعتماد على accepts التي تعيدها واجهة برمجة التطبيقات عند الاستدعاء الفعلي. مخرجات Facilitator /supported:
تفسير النتيجة:
  • توضح /supported أن Facilitator يمتلك قدرات التحقق والتسوية لهذه الشبكات والمخططات.
  • تدعم Base وSKALE وSolana exact؛ بينما upto متاحة حاليًا فقط على Base.
  • لا يزال يتعين الاعتماد على واجهة برمجة التطبيقات الخاصة بـ 402 accepts لتحديد ما إذا كانت واجهة برمجة التطبيقات تسمح بشبكة معينة.