الوجبات الأساسية
واجهة برمجة التطبيقات REST هي نوع من واجهات برمجة التطبيقات (API) يتبع مجموعة من قواعد التصميم التي تسمح لأنظمة البرمجيات بالتواصل عبر الإنترنت، وغالبًا ما يتم ذلك باستخدام HTTP.
تُستخدم واجهات برمجة التطبيقات REST على نطاق واسع في مجال العملات المشفرة والتمويل، بما في ذلك بواسطة منصات تداول API التي تُمكّن المطورين من أتمتة الأوامر، واسترداد بيانات السوق، وإدارة الحسابات برمجيًا.
تشمل المبادئ الأساسية لواجهات REST التواصل عديم الحالة، وواجهة موحّدة، وقابلية التخزين المؤقت (cacheability)، وبنية طبقية (layered) لكل منها دور في جعل واجهات البرمجة قابلة للتوسع وموثوقة.
فهم طلبات واستجابات REST API، بما في ذلك طرق HTTP و عناوين URL والترويسات وأكواد الحالة، ضروري لأي شخص يعمل مع أدوات المطورين أو يبني تكاملات.
مقدمة
تحتاج أنظمة البرمجيات إلى مشاركة البيانات عبر منصات وبيئات مختلفة. تمكن Application Programming Interfaces (APIs) من ذلك عبر توفير طريقة معيارية لتواصل مكونات البرمجيات معًا.
ضمن الأنماط المختلفة للـ API، أصبحت نقل الحالة التمثيلية (Representational State Transfer - REST) واحدة من أكثر الأنماط استخدامًا. فهي بسيطة ومرنة ومتوافقة مع معظم التقنيات. يوضح هذا المقال كيفية عمل REST وما الذي يتكون منه طلب واستجابة REST API النموذجيان.
تُعد REST APIs ذات صلة خاصة لأي شخص مهتم بتطوير الكريبتو أو الأتمتة. تعرض العديد من المنصات خدماتها عبر REST APIs، مما يسمح للمطورين بالاستعلام عن البيانات وإجراء الطلبات ودمج الوظائف داخل تطبيقاتهم الخاصة.
معايير بنية REST
يمثل Representational State Transfer (REST) أسلوبًا معماريًا للبرمجيات يضع قواعد لبناء خدمات الويب والتفاعل معها. تُسمى الأنظمة التي تتبع هذه القواعد بأنظمة RESTful. يحدث التواصل في REST عادةً عبر HTTP، باتجاه واحد في كل مرة:
العميل: يرسل طلبًا للوصول إلى مورد أو تغييره.
الخادم: يرد على العميل بالبيانات المطلوبة أو بتأكيد على الإجراء.
يُعد REST API هو النوع المحدد من الـ API الذي يتيح التواصل بين العميل والخادم على هذا النحو. ويتبع خمس مبادئ رئيسية:
هندسة العميل-الخادم: العميل والخادم مستقلان. يوفّر الخادم الموارد؛ يطلبها العميل. يساعد هذا الفصل كل طرف على التركيز على مهمته الخاصة.
تواصل عديم الحالة: يجب أن يتضمن كل طلب جميع المعلومات التي يحتاجها الخادم لمعالجة الطلب. لا يقوم الخادم بتخزين أي بيانات جلسة بين الطلبات.
قابلية التخزين المؤقت: ينبغي أن تشير الاستجابات إلى ما إذا كان يمكن تخزينها مؤقتًا. يقلل التخزين المؤقت من عدد الطلبات المتكررة ويمكن أن يحسن الأداء.
نظام متعدد الطبقات: يمكن للعميل التفاعل مع الخادم عبر طبقات وسيطة مثل موازنات التحميل أو طبقات الأمان دون الحاجة إلى معرفة أنها موجودة.
واجهة موحدة: تتبع جميع التفاعلات بروتوكولًا مشتركًا. عمليًا، يعني ذلك استخدام طرق HTTP قياسية وبنى عناوين URL متسقة.
HTTP هو أكثر بروتوكول شائع لبناء REST. إن دعمه المضمّن للتواصل عديم الحالة، وقابلية التخزين المؤقت، ومجموعة الطرق القياسية يجعله خيارًا مناسبًا بشكل طبيعي للتصميم المتوافق مع REST.
طلب العميل
البنية
يتكوّن طلب REST API من المكوّنات التالية:
1. طريقة HTTP: تحدد نوع العملية المراد تنفيذها. تُقابل الطرق الأربع الأساسية عمليات البيانات الأساسية (وغالبًا ما يُشار إليها باسم CRUD).
GET: يسترجع البيانات دون تغييرها.
POST: يرسل بيانات لإنشاء مورد جديد.
PUT: يستبدل أو ينشئ موردًا في موقع محدد.
DELETE: يزيل موردًا محددًا.
توجد طرق أخرى مثل PATCH وHEAD وOPTIONS، لكنها أقل استخدامًا في التطبيقات الأساسية.
2. URL (محدد موقع الموارد الموحد): يحدد نقطة النهاية الخاصة بالـ API المستهدفة، بما في ذلك عنوان الخادم الأساسي، والمسار المؤدي إلى المورد المحدد.
3. الترويسات (Headers): توفر سياقًا إضافيًا للطلب. من الترويسات الشائعة:
Content-Type: تنسيق البيانات التي يتم إرسالها، مثل application/json.
Accept: التنسيق الذي يمكن للعميل التعامل معه في الاستجابة.
مفتاح API / Authorization: بيانات اعتماد المصادقة التي تتحقق من هوية العميل.
4. نص الطلب (Request body): يُستخدم مع طلبات POST وPUT لإرسال البيانات إلى الخادم. عادةً ما يكون هذا النص بتنسيق JSON أو XML.
5. معلمات الاستعلام (Query parameters): فلاتر اختيارية تُضاف إلى عنوان URL بعد علامة الاستفهام. على سبيل المثال, ?sort=asc تقوم بفرز النتائج بترتيب تصاعدي. غالبًا ما تستخدم طلبات GET معلمات الاستعلام بدلًا من نص الطلب.
مثال
GET /users?sort=asc HTTP/1.1
Host: api.example.com
Accept: application/json
User-Agent: PostmanRuntime/7.40.0يسترجع طلب GET هذا قائمة بالمستخدمين من api.example.com، مرتبة تصاعديًا، ويتوقع استجابة بصيغة JSON، باستخدام أداة Postman.
POST /users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Accept: application/json
User-Agent: PostmanRuntime/7.40.0
{
"name": "John Doe",
"email": "john.doe@example.com"
}يقوم طلب POST هذا المرسل إلى api.example.com بإنشاء مستخدم جديد بالاسم "John Doe" وبريد "john.doe@example.com"، عبر إرسال بيانات نص الطلب بتنسيق JSON ويتوقع استجابة JSON، باستخدام أداة Postman.
استجابة الخادم
البنية
بعد أن يرسل العميل طلبًا، يعيد الخادم استجابة تتضمن ثلاثة أجزاء رئيسية:
1. رمز الحالة (Status code): رقم من ثلاثة أرقام يشير إلى نتيجة الطلب.
1xx (إعلامي): يتم معالجة الطلب.
2xx (نجاح): تم استلام الطلب ومعالجته بنجاح.
3xx (إعادة توجيه): يحتاج العميل إلى اتخاذ إجراء إضافي لإتمام الطلب.
4xx (خطأ من جهة العميل): توجد مشكلة في الطلب، مثل فقدان المصادقة أو وجود نقطة نهاية غير صالحة.
5xx (خطأ من جهة الخادم): تعذر على الخادم تلبية طلب صالح. تشير استجابة 429 Too Many Requests إلى أنك بلغت حدود المعدل (rate limits)، وهو أمر مهم فهمه عند العمل مع واجهات برمجة تطبيقات الكريبتو.
2. الترويسات: توفر بيانات وصفية عن الاستجابة، مثل Content-Type وContent-Length وCache-Control وDate.
3. النص (Body): البيانات الفعلية التي تُرجعها الـ API، غالبًا بتنسيق JSON أو XML.
مثال
إذا طلب عميل بيانات مستخدم باستخدام GET /users/123، فقد تبدو الاستجابة الناجحة مثل:
HTTP/1.1 200 OKContent-Type: application/json{"id": 123, "name": "John Doe", "email": "john.doe@example.com"}
تتضمن هذه الاستجابة رمز حالة 200 OK (نجاح)، وترويسة نوع المحتوى (JSON)، وبيانات المستخدم داخل النص.
حالات الاستخدام الشائعة
تخدم REST APIs مجموعة واسعة من الأغراض في تطوير البرمجيات:
تكاملات بين الشركات (B2B): تستخدم الشركات REST APIs لمشاركة الخدمات والبيانات مع شركاء الأعمال بطريقة معيارية.
منصات للمستهلكين (B2C): تستخدم التطبيقات الموجهة للمستهلك REST APIs لإتاحة الميزات للمستخدمين، مثل إدارة الحسابات أو استرداد البيانات.
الأنظمة الداخلية: يستخدم المطورون REST APIs للاتصال بالخدمات الداخلية، وتحسين تدفق البيانات بين أجزاء مختلفة من المؤسسة.
الكريبتو والتمويل: تُظهر البورصات REST APIs للمطورين حتى يتمكنوا من أتمتة استراتيجيات التداول، وجلب بيانات الأسعار، وإدارة المحافظ برمجيًا.
يرجع الدعم الواسع لـ REST إلى أنه يمكنه العمل عبر تقريبًا أي لغة أو منصة، وهو جزء من سبب بقائه أحد أنماط الـ API المهيمنة لأكثر من عقدين.
الأسئلة الشائعة (FAQ)
ما هي REST API باختصار؟
REST API هي طريقة لأنظمة البرمجيات للتواصل عبر الإنترنت باستخدام قواعد HTTP القياسية. يقوم نظام واحد (العميل) بإرسال طلب، ويرسل نظام آخر (الخادم) استجابة. تخيلها مثل تقديم طلب في مطعم: تقوم بتقديم الطلب، ويعيد الخادم ما طلبته.
ما الفرق بين REST وSOAP APIs؟
REST وSOAP كلاهما أسلوبان لبناء الـ API، لكنهما يعملان بشكل مختلف. SOAP (بروتوكول الوصول إلى الكائنات البسيط) هو معيار أقدم يستخدم XML ويحتوي على قواعد صارمة. REST أكثر مرونة، ويدعم تنسيقات بيانات متعددة (بما في ذلك JSON)، وغالبًا ما يكون أسهل في التعامل. وقد حلت REST إلى حد كبير محل SOAP في أغلب واجهات الويب البرمجية الحديثة.
ماذا يعني عديم الحالة (stateless) في REST؟
يعني عديم الحالة أن الخادم لا يتذكر أي شيء عن الطلبات السابقة. يجب أن يحتوي كل طلب على جميع المعلومات اللازمة لمعالجة الخادم له. وهذا يجعل REST APIs أسهل للتوسع لأن الخادم لا يحتاج إلى الاحتفاظ ببيانات الجلسة بين الاستدعاءات.
ما طرق HTTP الأكثر استخدامًا في REST APIs؟
أكثر الطرق الأربع استخدامًا في HTTP هي GET (استرجاع البيانات)، وPOST (إنشاء مورد)، وPUT (استبدال أو إنشاء مورد)، وDELETE (إزالة مورد). وبالاقتران، فإنها تقابل عمليات الإنشاء والقراءة والتحديث والحذف (CRUD) الأساسية المستخدمة في معظم أنظمة البرمجيات.
كيف ترتبط REST API بواجهات WebSocket APIs؟
تتبع REST APIs نموذج طلب-استجابة: ترسل طلبًا ثم تحصل على استجابة. تعمل WebSocket API بشكل مختلف عبر الحفاظ على اتصال مفتوح، مما يسمح للخادم بدفع البيانات إلى العميل في الوقت الفعلي دون انتظار طلب. يُعد REST مناسبًا أكثر للعمليات القياسية مثل جلب بيانات الحساب، بينما تكون WebSockets أكثر كفاءة لتيارات البيانات في الزمن الحقيقي مثل بث أسعار مباشر.
أفكار ختامية
تُعد REST APIs جزءًا أساسيًا من طريقة تفاعل أنظمة البرمجيات الحديثة. ومن خلال الالتزام بمجموعة واضحة من القواعد حول طرق HTTP و عناوين URL والترويسات وأكواد الحالة، تتيح REST بناء خدمات قابلة للتوسع وقابلة للتشغيل البيني عبر أي مجموعة تقنيات تقريبًا.
بالنسبة لأي شخص يعمل مع أدوات مطوري الكريبتو، فإن فهم REST APIs يُعد بداية عملية. تعرض العديد من البورصات، بما في ذلك Binance، وظائفها الأساسية عبر REST APIs. إذا كنت ترغب في استكشاف كيفية تطبيق هذه المفاهيم مباشرة، فإن دليل Binance Spot REST API خطوة تالية مفيدة.
قراءات إضافية
إخلاء المسؤولية: يتم تقديم هذا المحتوى لك "كما هو" لأغراض المعلومات العامة و/أو التعليمية فقط، دون أي تمثيل أو ضمان من أي نوع. لا ينبغي اعتباره نصيحة مالية أو قانونية أو غيرها من النصائح المهنية، ولا يهدف إلى التوصية بشراء أي منتج أو خدمة محددة. يجب عليك طلب نصيحتك الخاصة من مستشارين مهنيين مناسبين. وعندما يتم المساهمة بالمحتوى من قبل طرف ثالث، يرجى ملاحظة أن الآراء الواردة فيه تخص المساهم/الطرف الثالث، ولا تعكس بالضرورة آراء Binance Academy. قد تكون أسعار الأصول الرقمية متقلبة. قد ينخفض أو يرتفع سعر استثمارك وقد لا تتمكن من استرداد المبلغ المستثمر. أنت وحدك المسؤول عن قراراتك الاستثمارية، وBinance Academy ليست مسؤولة عن أي خسائر قد تتكبدها. لمزيد من المعلومات، راجع شروط الاستخدام وتحذير المخاطر وشروط Binance Academy.