ما هي واجهة REST API؟
الإجابة المباشرة
تُعد REST API (واجهة برمجة تطبيقات نقل الحالة التمثيلية Representational State Transfer Application Programming Interface) طريقةً لطلب بيانات أو تنفيذ إجراءات من نظام برمجي آخر عبر الويب باستخدام طرق HTTP قياسية (مثل GET وPOST وPUT وDELETE). تعمل عادةً عبر إرسال طلبات إلى نقاط نهاية URL، واستلام استجابات بتنسيق منظم (غالبًا JSON)، دون الحاجة إلى أن يحتفظ الخادم بحالة الجلسة بين المكالمات.
في سياق الفوركس، يستخدم الناس REST APIs لدمج أدوات خارجية—مثل لوحات المعلومات أو خدمات التنفيذ أو تقارير المكتب الخلفي—حتى يتمكنوا من التواصل مع المنصة برمجيًا. يشرح هذا المقال الفكرة والآليات العملية على مستوى عالٍ، مع توضيح الحدود المهمة عندما تحاول التحقق من السلوك.
كيف تعمل REST API
REST هو نمط معماري لتصميم واجهات برمجة التطبيقات. الخصائص الأساسية التي تظهر غالبًا في REST APIs هي:
- تفاعلات عديمة الحالة: يجب أن يتضمن كل طلب معلومات كافية لفهمه من قِبل الخادم، دون الاعتماد على سياق جلسة مخزّن.
- عناوين URL قائمة على الموارد: تمثل نقاط النهاية موارد (على سبيل المثال، “orders” أو “accounts”) بدلًا من إجراء عام واحد.
- دلالات HTTP قياسية: يُستخدم GET غالبًا للاسترجاع، بينما تُستخدم POST/PUT/DELETE غالبًا لإنشاء الموارد أو تحديثها أو إزالتها.
- نمط استجابة موحّد: تُرجع الاستجابات رمز حالة HTTP بالإضافة إلى حمولة (payload) تصف النتيجة (على سبيل المثال، بيانات النجاح أو وصف الخطأ).
نموذج بسيط هو: يقوم عميلك ببناء طلب HTTP → يعالجه الخادم → يعيد الخادم استجابة. ولأغراض التحقق، يمكنك فحص ما إذا كانت الاستجابات تتضمن رموز حالة واضحة، وما إذا كانت الأخطاء قابلة للتنبؤ وقابلة للقراءة بواسطة الآلة، وما إذا كانت المكالمات المتكررة تتصرف بشكل متسق مع افتراض “عديم الحالة”.
الدليل والمثال (غير فوري)
تخيل وجود نظامين: أداة داخلية (العميل) ومنصة فوركس (الخادم). لنفترض أن العميل يريد استرجاع معلومات حول الأوامر الموجودة.
- يرسل العميل طلب GET إلى نقطة نهاية تمثل “orders”.
- يعيد الخادم حمولة استجابة تحتوي على تفاصيل الأوامر ورمز حالة HTTP يشير إلى النجاح أو الفشل.
- إذا احتاج العميل بعد ذلك إلى وضع أمر جديد، فإنه يرسل طلب POST إلى نقطة نهاية “إنشاء الأمر” ذات الصلة.
حتى بدون بيانات سوق فورية، يوضح هذا الفكرة الأساسية لـ REST API: تطلب موارد أو إجراءات باستخدام HTTP، ثم تفسر رمز الحالة والبيانات التي تم إرجاعها. ما لا ينبغي افتراضه هو أن “إرسال الطلب” يعني “نجاح التنفيذ”. قد يتم قبول الطلب من الشبكة لكن يفشل لاحقًا بسبب قواعد التحقق، أو فحوصات الصلاحيات، أو تغيّر ظروف النظام.
القيود والمخاطر، وكيفية التحقق
قد تكون عملية تكامل REST API سهلة من الناحية المفاهيمية، لكن الأنظمة الواقعية تُدخل عدم يقين. تشمل القيود وأنماط الفشل ما يلي:
- مشكلات الشبكة والكمون: قد تتأخر الطلبات أو تنتهي بمهلة (timeout) أو تفشل بشكل متقطع.
- حالات فشل جزئية: قد تتلقى خطأ حتى بعد أن عالج الخادم جزءًا من سير عمل، أو قد تحتاج إلى إعادة المحاولة مع ضمانات idempotency.
- الصلاحيات والتحقق من صحة البيانات: قد تمنع المصادقة والتفويض والتحقق من صحة المدخلات الطلبات.
- تغيّر الظروف الخارجية: في سير عمل الفوركس، يمكن أن تتغير التكاليف وبيئة التنفيذ وحالة السوق بين لحظة إنشاء الطلب ولحظة معالجته.
لأجل تحقق مستقل، ركّز على الحقائق القابلة للرصد في الوثائق أو سلوك الـ API: رموز الاستجابة الموثقة، وتنسيق رسائل الأخطاء، وإرشادات إعادة المحاولة، والحد من المعدل (rate limiting)، وما إذا كانت الـ API توضح بوضوح متطلبات المصادقة وافتراضات الحالة.
التحقق والسؤال التالي
إذا كنت تريد خطوة إضافية، اسأل عن “resources” التي تعرضها REST API في سير عمل الفوركس الذي تهتم به (على سبيل المثال، نقاط نهاية مرتبطة بالأوامر مقابل نقاط نهاية التقارير)، وكيف يتم توصيل النجاح والفشل عبر رموز الحالة وحمولات الاستجابة. يتيح ذلك التحقق من السلوك دون الاعتماد على الوعود المتعلقة بالنتائج.