تقدم واجهة برمجة التطبيقات أو واجهة برمجة التطبيقات وظائف وقواعد تسمح بالتفاعل والتواصل بين التطبيقات المختلفة. تسهل هذه الواجهات تكامل التطبيقات ، وتمكن المطورين من إنشاء منتجات رقمية قوية.
تتوسط واجهة برمجة التطبيقات بين التطبيقات عبر الطلبات والاستجابات. على سبيل المثال ، يحدث التسجيل في التطبيق من خلال حساب Twitter الحالي للمستخدم من خلال Twitter API التي قام المطورون بدمجها في التطبيق. 
- XML-RPC - يسمح بتبادل الوظائف بين الشبكات. يستخدم XML-RPC XML لوصف الاستجابات / الطلبات وبروتوكولات HTTP لنقل المعلومات من العميل إلى الخادم.
- JSON-RPC هو RPC خفيف الوزن مشابه لـ XML. هنا يتم ترميز البروتوكول في JSON ؛ يسمح باستقبال المكالمات إلى الخادم باستجابات غير متزامنة.
- SOAP - بروتوكول وصول بسيط إلى كائن لتبادل المعلومات المنظمة عند تنفيذ خدمات الويب في شبكات الكمبيوتر. يستخدم SOAP XML للمصادقة والتفويض وعملية الاتصال على أنظمة التشغيل. يسمح للعملاء بالاتصال بخدمات الويب وتلقي الردود بغض النظر عن النظام الأساسي واللغة.
- REST API (نقل الحالة التمثيلية) - أسلوب معماري يستخدم تطبيقات خادم العميل بشكل مستقل. يستخدم REST بروتوكول HTTP للاتصال.
في هذا المنشور ، نركز على واجهة برمجة تطبيقات REST ، ونعرّفها ، ونحلل كيف تختلف عن واجهات برمجة التطبيقات الأخرى.
تحديد REST API
REST هو أسلوب معماري لتصميم واجهات برمجة التطبيقات من خلال بروتوكول HTTP. فائدتها الرئيسية هي مرونتها الكبيرة.
يستخدم المطورون واجهة برمجة تطبيقات REST حيثما كانت هناك حاجة لتوفير البيانات لمستخدم تطبيق الويب أو الموقع مباشرة من الخادم. 
- عميل - عميل أو برنامج يتم تشغيله من جانب المستخدم (على جهازه) لبدء الاتصال.
- الخادم - خادم يستخدم واجهات برمجة التطبيقات للوصول إلى وظائفه وبياناته.
- الموارد - أي محتوى (فيديو ، نص ، صورة) يرسله الخادم إلى العميل.
كيف تعمل واجهة برمجة تطبيقات REST
تتواصل REST API من خلال طلبات HTTP ، وتستكمل الوظائف التالية - إنشاء البيانات وقراءتها وتحديثها وحذفها. تُعرف أيضًا باسم عمليات CRUD. يوفر REST معلومات حول الموارد المطلوبة ويستخدم أربع طرق لوصف ما يجب فعله بالمورد:
ما بعد - إنشاء مورد ؛
الحصول على - الحصول على مورد ؛
PUT - تحديث مورد ؛
حذف - حذف مورد.
الموارد
المورد هو مفهوم مهم في REST API ، وهو تجريد للمعلومات. يمكن أن يكون أي معلومات: وثيقة ، صورة ، خدمة مؤقتة.
تُعرف حالة المورد في أي لحظة معينة باسم تمثيل الموارد الذي يتكون من البيانات والبيانات الوصفية التي تصف البيانات وروابط الوسائط التشعبية لمساعدة العملاء على الانتقال إلى الحالة التالية.
يمكن تسليم المعلومات إلى العميل بتنسيقات مختلفة: JSON أو HTML أو XLT أو Python أو نص عادي. الأكثر شيوعًا واستخدامًا هو JSON لأنه يمكن قراءته بواسطة الإنسان والآلة ومحايد اللغة.
للوصول إلى مورد ، يحتاج العميل إلى تقديم طلب. بعد استلامه ، سيقوم الخادم بإنشاء استجابة ببيانات مشفرة حول أحد الموارد.
تتضمن بنية الطلب أربعة مكونات رئيسية: طريقة HTTP (CRUD التي ذكرناها سابقًا) ونقاط النهاية والعناوين والجسم.
تصف طريقة HTTP ما يجب القيام به مع المورد. أعلاه ، ذكرنا أربع طرق متاحة: POST ، GET ، PUT ، DELETE.
تحتوي نقطة النهاية على URI - معرّف الموارد المنتظم ، الذي يشير إلى كيفية ومكان العثور على المورد. عنوان URL أو موقع المورد الموحد هو أكثر أنواع URI شيوعًا ، ويمثل عنوان ويب كاملًا.
تحتوي الرؤوس على البيانات المتعلقة بالعميل والخادم. تتضمن الرؤوس بيانات المصادقة: مفتاح API والاسم وعنوان IP الخاص بالكمبيوتر المثبت عليه الخادم ، وكذلك المعلومات المتعلقة بتنسيق الاستجابة.
يتم استخدام النص لإرسال معلومات إضافية إلى الخادم ، مثل البيانات التي تريد إضافتها.
مبادئ REST API
لا ترتبط REST بأي تقنية أو منصة معينة. إنها لغة مستقلة. كما أنه لا يحدد بدقة كيفية إنشاء واجهة برمجة التطبيقات. لكنها تستخدم ستة قيود معمارية. يمكن تسمية الواجهة بواجهة برمجة تطبيقات REST صالحة باتباع تلك القيود. يصفون كيف يعالج الخادم الطلبات ويستجيب لها.
خدمة الزبائن
تنفذ واجهة برمجة تطبيقات REST نمط بنية خادم العميل. يرسل العميل طلبات للحصول على الموارد ولا يرتبط بتخزين البيانات. يبقى تخزين البيانات داخل الخادم. لا تشارك الخوادم في الاتصال بواجهة المستخدم. العميل والخادم يتطوران بشكل مترابط. هذا العامل يجعل REST أكثر مرونة وقابلية للتطوير.
واجهة موحدة
الواجهة الموحدة هي عامل أساسي يميز واجهة برمجة تطبيقات REST. تنص على أن هناك طريقة واحدة للاتصال بالخادم ، ولا تشير إلى نوع التطبيق والجهاز.
للواجهة الموحدة أربعة مبادئ:
- تحديد الموارد. يجب أن يكون لكل مورد تعريف مستقل عن حالة الموارد. يعمل عنوان URL كمعرف.
- التلاعب بالموارد من خلال التمثيلات. يحتوي تمثيل المورد (الذي يمتلكه العميل) على البيانات المطلوبة لحذف أو تعديل المورد. يرسل العميل إقرارًا بأن الخادم (كائن JSON) يحتاج إلى التعديل أو الإزالة أو الإضافة.
- رسائل وصفية ذاتية. تحتوي هذه الرسائل على جميع المعلومات للمتلقي لفهمها. لا توجد معلومات إضافية مطلوبة في وثائق أو رسائل منفصلة. تحتوي كل رسالة على معلومات كافية للخادم لتحليل الطلب.
- الوسائط الفائقة كمحرك لتطبيق الحالة. تتطلب الوسائط التشعبية استخدام الروابط لكل استجابة حتى يتمكن العميل من العثور على موارد أخرى. في REST ، يتم استخدام الوسائط التشعبية لجميع التفاعلات.
عديم الجنسية
هذا يعني أن الخادم لا يحتوي على أي بيانات عن العميل. يتم تضمين جميع المعلومات اللازمة لمعالجة الطلب في الطلب. يخزن العميل جميع معلومات الجلسة.
قابل للتخزين المؤقت
يجب أن تحتوي كل استجابة على المعلومات التي توضح ما إذا كانت قابلة للتخزين المؤقت أم لا ويمكن تخزين فترة الاستجابة مؤقتًا. إذا كانت قابلة للتخزين المؤقت ، ففي الطلبات المماثلة ، يمكن للعميل استخدام نفس البيانات دون إرسال الطلبات بشكل متكرر إلى الخادم. يساعد على تحسين الأداء والتوافر.
نظام الطبقات
يطبق REST التسلسل الهرمي للطبقات ، والذي ينشئ قيودًا معينة على سلوك المكونات. في نظام الطبقات ، يمكن للمكونات فقط رؤية المكونات الموجودة في أقرب المستويات وتلك التي تتفاعل معها.
كود عند الطلب
إنها ميزة اختيارية تتيح للعملاء تنزيل التعليمات البرمجية وتنفيذها.
ما الذي يميز REST API؟
يمكن اعتبار المبادئ الستة لـ REST API الاختلافات الرئيسية بين هذه الواجهة والأنواع الأخرى. بالإضافة إلى ذلك ، هناك العديد من المعلمات التي تميز REST.
أولاً ، يحدد جوهر REST عدم توافقه مع الأنواع الأخرى. إنه أسلوب معماري حيث تمثل الهندسة المعمارية مجموعة من المتطلبات التي تحتاج إلى اتباعها لتوفير خدمة ويب RESTful. على سبيل المثال ، يعد SOAP و RPC بروتوكولات مراسلة تصف الرسائل. على عكس النمط المعماري ، الذي يحدد فقط المتطلبات (القيود) التي يجب أن تفي بها الرسالة.
بنية
عادةً ما تتبع واجهة برمجة التطبيقات تنسيق التطبيق من التطبيق إلى التطبيق ، بينما تتبع REST بنية مختلفة - خادم العميل. يتطور العميل والخادم بشكل مستقل ، مما يوفر مزيدًا من المرونة في العمل.
تنسيق تبادل الرسائل
عادةً ما تستخدم واجهات برمجة التطبيقات تنسيقات رسائل محددة ؛ على سبيل المثال ، يستخدم SOAP XML. لا تتبع REST مثل هذا المبدأ الصارم. يمكنه استخدام أي تنسيق تقريبًا لتبادل البيانات. ومع ذلك ، فإن JSON هي الآن الأكثر شعبية.
هناك أسباب واضحة وراء شعبية JSON - يمكن قراءتها من قبل الإنسان ومن السهل تحليل تنسيق تبادل البيانات. JSON مستقل عن اللغة ، ويمكنك استخدامه مع أي لغة بخلاف JavaScript.
المرونة
REST هو أسلوب معماري مرن ، لذلك يستخدمه المطورون على نطاق واسع. بالمقارنة مع SOAP - وهو بروتوكول أكثر تعقيدًا مع ميزات أمان متقدمة تتطلب مزيدًا من عرض النطاق الترددي ، يتكون REST من إرشادات بسيطة تسمح للمطورين باستخدام هذه المتطلبات بتنسيقهم. توفر البنية أداءً عاليًا ، مما يجعلها مطلوبة بشكل خاص للأجهزة المحمولة ، حيث تكون سرعة التنزيل مهمة.
كما نرى ، تتمتع REST بمزايا معينة على واجهات برمجة التطبيقات المعروفة الأخرى. هذا هو السبب في أن جميع الشركات الرائدة مثل Twitter و Google قد طبقتها على منتجاتها. بعد كل شيء ، إنها الطريقة المثالية والسهلة لنقل البيانات إلى المطورين حول العالم وآلية مجربة لإنشاء واجهات فعالة وقابلة للتطوير لتطوير البرامج.
