تعريف REST API: ما هي واجهة برمجة تطبيقات REST (RESTful API)؟

By |2021-10-20T07:14:43+00:0028 يناير، 2020|

"ما هي API وكيف تعمل؟" هو سؤال يتم طرحه بشكل متكرر. ان API (واجهة برنامج التطبيق) هي مجموعة من القواعد التي تمكن البرامج المختلفة من التواصل مع بعضها البعض. توضح الطريقة المناسبة لمطور البرامج لإنشاء برنامج على خادم يتواصل مع تطبيقات العميل المختلفة.

يشير تكامل واجهة برمجة التطبيقات (API) إلى تطبيقين (تطبيقين أو أكثر) متصلين ببعضهما البعض من خلال واجهات برمجة التطبيقات الخاصة بهم لتبادل البيانات وأداء وظيفة مشتركة ، وبالتالي ، تمكين التفاعل بين التطبيقات. الآن بعد أن حددنا API ، دعنا ننتقل نحو REST APIs. تستخدم مواقع الويب المختلفة مثل Amazon و Google و Facebook و LinkedIn و Twitter واجهات برمجة التطبيقات القائمة على REST والتي تتيح للمستخدمين التواصل مع هذه الخدمات السحابية.

ستناقش هذه المقالة ماهية REST API وكيف تعمل. بعد ذلك ، سننظر في سبب تحول واجهة برمجة التطبيقات هذه إلى وسيلة مفضلة للاتصال بين المستخدمين هذه الأيام وما هي واجهات برمجة تطبيقات RESTful المستخدمة. أخيرًا ، سنغطي المبادئ التوجيهية الستة التي يجب أن تضعها في اعتبارك أثناء إنشاء RESTful API.

ما هو REST API؟

في عام 2000 ، حدد Roy Fielding REST على أنه أسلوب ومنهجية معمارية تستخدم بشكل متكرر في تطوير خدمات الإنترنت ، مثل أنظمة الوسائط التشعبية الموزعة.

تعريف بقية API:

الشكل الكامل لـ REST API هو واجهة برمجة تطبيقات نقل الحالة التمثيلية المعروفة بشكل أكثر شيوعًا باسم خدمة الويب REST API. هذا يعني أنه عندما يتم استدعاء RESTful API ، سيقوم الخادم بذلك تحويل a التمثيل من المورد المطلوب حالة لنظام العميل.

على سبيل المثال ، عندما يطلب أحد المطورين من Twitter API لجلب كائن مستخدم (مورد) ، ستعيد واجهة برمجة التطبيقات (API) حالة هذا المستخدم واسمه ومتابعيه والمنشورات التي تمت مشاركتها على Twitter. هذا ممكن بسبب تكامل API.

يمكن أن يكون تمثيل الحالة هذا بتنسيق JSON أو XML أو HTML.

تعريف REST API

(المصدر: Seobility)

توفر بروتوكولات نقل البيانات النموذجية ، مثل SOAP (بروتوكول الوصول البسيط للكائنات) إمكانيات رائعة في شروط أمن البيانات وسلامتها. علاوة على ذلك ، يوفر SOAP منطق إعادة المحاولة المدمج للتعويض عن الاتصالات غير الناجحة. لكن مثل هذه البروتوكولات يصعب العمل عليها أيضًا. RESTful API هو بديل أبسط تم تطويره بشكل كبير في السنوات القليلة الماضية. غالبًا ما يتم الخلط بين الناس فيما يتعلق بمعايير REST. بالمقارنة مع SOAP ، خدمات الويب القديمة ، فإن REST أكثر مرونة وسهولة في التنفيذ.

عادةً ما يُفضل استخدام REST على SOAP الأكثر قوة مثل الاستخدامات السابقة عرض نطاق أقل، مما يجعلها أكثر ملاءمة لخدمات الويب العالمية. يستخدم بروتوكول HTTP لجلب البيانات أو تنفيذ العمليات بتنسيقات متعددة (مثل XML و JSON) ، مما يسمح بعمليات أسرع.

ونتيجة لذلك ، يستخدم SOAP نقل بيانات XML ، وتعريف العمليات كمنافذ WSDL أحادية الاتجاه مع العديد من مثيلات العملية التي تشترك في نفس العملية. في REST ، يتم تعريف العمليات في الرسائل نفسها. علاوة على ذلك ، هناك اتجاه واحد لكل مثيل عملية.

هناك اختلاف آخر بين SOAP و REST يكمن في طريقة اقتران هذه البروتوكولات. SOAP مرتبط بإحكام ، في حين أن الأخير مرتبط بشكل ضعيف. يعني الاقتران الضعيف أن الوحدات النمطية مستقلة ، والاختلافات في إحداها لا تزعج عمل الآخرين. نتيجة لذلك ، هناك مرونة وقابلية لإعادة الاستخدام عند إضافة الوحدات أو استبدالها أو تعديلها. من ناحية أخرى ، يعني الاقتران المحكم أن الوحدات تميل إلى أن تكون معتمدة على بعضها البعض. لذلك ، يمكن أن يكون للاختلافات في وحدة واحدة تأثير على مستوى النظام. كل هذه الاختلافات هي التي تجعل واجهة برمجة التطبيقات (API) مريحة.

في الوقت الحالي ، تستخدم العديد من التطبيقات والمشاريع REST APIs لنقل البيانات ، كما تتبنى الشركات بشكل متزايد خدمات الويب RESTful للاستمتاع بالنمو الأفقي.

كيف تعمل واجهة برمجة تطبيقات REST؟

يحدد REST بنية ملف API. يلتزم المطورون بمجموعة معينة من القواعد عند تصميم واجهة برمجة التطبيقات. على سبيل المثال ، تنص إحدى القواعد على أن الارتباط بعنوان URL يجب أن يعرض بعض المعلومات.

يُعرف كل عنوان URL باسم طلب ، في حين تُعرف البيانات التي يتم إرجاعها باسم الاستجابة.

REST API يكسر المعاملة لإنشاء سلسلة من المكونات الصغيرة. يتناول كل مكون جانبًا أساسيًا محددًا من المعاملة. هذا النموذج يجعل منه نهج تطوير مرن.

تستفيد واجهة برمجة تطبيقات REST من طرق HTTP الموصوفة بواسطة بروتوكول RFC 2616. يستخدم الطلبات التالية:

  • الحصول على لجلب البيانات
  • ضع لتغيير حالة البيانات (مثل كائن أو ملف أو كتلة)
  • سأعين لإنشاء البيانات
  • حذف للقضاء عليه

يمكن رؤية رموز حالة HTTP المختلفة التي تستخدمها REST APIs هنا.

ما هي RESTful APIs المستخدمة؟

لفهم واجهة برمجة تطبيقات REST وكيفية عملها بشكل أفضل ، دعنا نفكر في مثال.

افترض أنك تريد مشاهدة دروس فيديو حول "تكامل البيانات" على موقع يوتيوب. انتقل إلى YouTube ، واكتب "تكامل البيانات" في حقل البحث ، واضغط على Enter ، وتظهر قائمة بمقاطع الفيديو حول تكامل البيانات. حق؟

تعمل واجهة برمجة تطبيقات RESTful بشكل مشابه. أنت تبحث عن شيء ما ، ويتم إرجاع قائمة النتائج من الخدمة المطلوبة.

في تقنية REST ، الافتراض هو أن جميع المكالمات عديمة الحالة. هذا يعني أن خدمة REST لا يمكنها الاحتفاظ بأي شيء بين عمليات التنفيذ ، مما يجعلها مفيدة في التطبيقات السحابية. وذلك لأنه يمكن إعادة تعيين المكونات عديمي الجنسية بسهولة في حالة الفشل. علاوة على ذلك ، يمكن تحجيمها بسهولة لمراعاة اختلافات الحمل. هذا لأنه يمكن إرسال أي طلب إلى أي مثيل من المكون.

نظرًا لعدم إمكانية الاحتفاظ بأي بيانات يجب استرجاعها من خلال المعاملة اللاحقة ، فإن REST هو البروتوكول المطلوب للاتصال بالإنترنت. كما ذكرنا سابقًا ، تعد تقنية REST API مفيدة أيضًا في الاتصال بالتطبيقات السحابية ، حيث إن الوصول إلى خدمة عبر واجهة برمجة التطبيقات يحتاج فقط إلى تعديل في تفسير عنوان URL.

وبالمثل ، يمكن أيضًا استخدام REST API لـ بيانات الخرائط من منصة سحابية إلى مستودع بيانات أو العكس.

مسرد مصطلحات REST API للمصطلحات الأساسية

قبل الغوص في المبادئ التوجيهية لتصميم واجهات برمجة تطبيقات REST ، دعنا نناقش بإيجاز ثلاثة مصطلحات رئيسية:

العميل

العميل عبارة عن جهاز أو برنامج يستخدم واجهة برمجة التطبيقات التي يمكن الوصول إليها بواسطة الخادم. على سبيل المثال ، عندما تزور موقع Facebook ، يكون متصفحك هو العميل الذي يتصل بواجهة برمجة تطبيقات Facebook ويستخدم البيانات المرسلة مرة أخرى لعرض المعلومات على شاشتك.

مورد

يمكن أن يكون المورد أي كائن يمكن لواجهة برمجة التطبيقات تقديم معلومات عنه. على سبيل المثال ، في حالة واجهة برمجة تطبيقات Twitter ، يمكن أن يكون المورد مستخدمًا أو علامة تصنيف أو أي نوع وسائط مثل الصورة. كل مورد له معرف مميز يمكن أن يكون اسمًا أو رقمًا.

المصدر هو التجريد الرئيسي للمعلومات في REST. تستخدم REST API معرف مورد للتعرف على المورد المحدد المتضمن في الاتصال بين العناصر المختلفة.

المخدم

الخادم هو أي نظام يحتوي على موارد يريدها العميل. عندما يتلقى طلبات العميل ، فإنه يوفر المحتوى للعميل باستخدام واجهة API. يمنح الخادم فقط حالة تمثيلية للمصدر وليس وصولاً كاملاً إلى العميل.

وخير مثال على ذلك هو عندما يعرض تطبيق الجوال مقاطع فيديو YouTube من خلال واجهته الخاصة. يستخدم واجهة برمجة تطبيقات REST لاستدعاء محتوى الفيديو من YouTube دون استضافته فعليًا على نظامه الخاص.

ميزات REST API

فيما يلي قائمة بالميزات التي تجعلها الطريقة الأكثر فاعلية لتكامل البيانات والتطبيقات.

التدرجية

تقدم REST API قابلية تطوير كبيرة. نظرًا للفصل بين العملاء والخوادم ، فإنه يسمح بتوسيع نطاق المنتج بواسطة فريق من المطورين دون الكثير من المتاعب.

بالإضافة إلى ذلك ، من الأسهل دمج REST مع المواقع الحالية دون إعادة هيكلة البنية التحتية لموقع الويب. يتيح ذلك للمطورين العمل بشكل أسرع بدلاً من قضاء الوقت في إعادة صياغة موقع الويب من البداية. كبديل ، يمكنهم فقط إضافة وظائف إضافية. هذا يجعلها الطريقة الأكثر استخدامًا للتكامل.

المرونة وقابلية النقل

يمكن للمستخدمين التواصل بسهولة حتى إذا كان خادم العميل REST مستضافًا خوادم مختلفة، مما يقدم فائدة مهمة من منظور الإدارة.

استقلال

بفضل الفصل بين العميل والخادم ، يجعل بروتوكول REST من السهل أن تحدث التطورات عبر المجالات المختلفة للمشروع بشكل مستقل. علاوة على ذلك ، فإن واجهة برمجة التطبيقات REST قابلة للتعديل وفقًا للقواعد التشغيلية والنظام الأساسي ، مما يوفر إمكانية اختبار العديد من البيئات أثناء التطوير.

مبادئ تصميم REST API

الآن بعد أن غطينا الأساسيات ، دعنا ننتقل إلى المبادئ التوجيهية الستة لتصميم REST API:

خادم العميل

يعمل مبدأ التصميم هذا على مفهوم أنه يجب عزل العميل والخادم عن بعضهما البعض والسماح له بالتطوير بشكل مستقل. بهذه الطريقة ، يمكنك تحسين قابلية الإدارة عبر العديد من الأنظمة الأساسية وزيادة قابلية التوسع من خلال تبسيط مكونات الخادم حيث تكون اهتمامات واجهة المستخدم منفصلة عن مخاوف تخزين البيانات.

عديم الجنسية

وفقًا لهذا المبدأ ، فإن REST APIs عديمة الحالة ، مما يعني أنه يمكن إجراء المكالمات بشكل مستقل عن بعضها البعض. علاوة على ذلك ، تتضمن كل مكالمة البيانات الأساسية لإكمال نفسها بفعالية.

بمعنى آخر ، يجب أن يتضمن كل طلب يتم إرساله من العميل إلى الخادم جميع المعلومات اللازمة لفهم الطلب.

قابلة للتخزين المؤقت

يمكن أن تتصاعد واجهة برمجة التطبيقات عديمة الحالة طلب النفقات العامة من خلال إدارة كميات ضخمة من المكالمات الواردة والصادرة ، يجب أن يكون تصميم REST API قادرًا على تخزين البيانات القابلة للتخزين المؤقت. وفقًا لمبدأ تصميم واجهة برمجة التطبيقات هذا ، يجب تصنيف البيانات ضمن الاستجابة بشكل غير مباشر أو واضح على أنها قابلة للتخزين المؤقت أو غير القابلة للتخزين المؤقت.

إذا كانت الاستجابة قابلة للتخزين المؤقت ، فسيتم منح ذاكرة التخزين المؤقت للعميل الحق في إعادة تدوير بيانات الاستجابة لطلبات مماثلة في المستقبل.

واجهة موحدة

لفصل عميل عن الخادم ، يجب أن يكون لديك واجهة موحدة تسمح بالتطوير المستقل للتطبيق دون ربط خدماته ونماذجه وإجراءاته بإحكام مع طبقة API نفسها.

يعمل مبدأ التصميم هذا على تبسيط بنية النظام بالكامل وتعزيز رؤية الاتصالات. للوصول إلى واجهة موحدة ، يلزم وجود العديد من عناصر التحكم المعمارية لتوجيه أداء العناصر داخل بنية REST API.

يتم تعريف REST بأربعة عناصر تحكم في الواجهة ، بما في ذلك تحديد الموارد ، وإدارة الموارد من خلال العروض ، والاتصالات الوصفية الذاتية ، والوسائط التشعبية كمحرك لحالة التطبيق.

نظام الطبقات

تتضمن بنية REST API عدة طبقات تعمل معًا لبناء تسلسل هرمي يساعد في إنشاء تطبيق أكثر مرونة وقابلية للتوسع. نظرًا لنظام الطبقات الخاص به ، يتمتع التطبيق بمستوى أمان أفضل حيث لا يمكن للمكونات الموجودة في كل طبقة التفاعل خارج الطبقة التالية. علاوة على ذلك ، فإنه يوازن بين الأحمال ويقدم مخابئ مشتركة للتحفيز التدرجية.

يتمتع نظام بنية REST API ذو الطبقات باستقرار أكبر لأنه يقيد أداء المكونات. بحيث يتعذر على كل مكون "رؤية" أبعد من الطبقة المباشرة التي يتداخل معها.

كود عند الطلب

يسمح مبدأ التصميم هذا بتوصيل الترميز أو التطبيقات الصغيرة من خلال واجهة برمجة التطبيقات لاستخدامها داخل التطبيق.

يسمح تعريف واجهة برمجة تطبيقات REST بتوسيع وظائف العميل عن طريق تنزيل الترميز وتنفيذه في شكل تطبيقات أو نصوص برمجية. يعمل هذا على تبسيط العملاء من خلال تقليل عدد الميزات الأساسية ليتم تنفيذها مسبقًا.

في معظم الأحيان ، يعرض الخادم تمثيل الموارد الثابت بتنسيق XML أو JSON. ولكن عند الحاجة ، يمكن للخوادم تقديم تعليمات برمجية قابلة للتنفيذ إلى العميل.

Astera Centerprise يجعل تكامل API المريح أمرًا سهلاً

للمطورين الجدد ، REST API يمكن أن يكون التكامل صعبًا حيث قد تفقد القدرة على الحفاظ على الحالة في REST ، كما هو الحال في الجلسات. لذلك ، من المهم فهم ما الذي يجعل REST API تحافظ على حالتها ولماذا توجد هذه المبادئ التوجيهية الستة قبل تصميم API الخاص بك.

على عكس SOAP ، لا يتطلب REST من العملاء معرفة دلالات العملية قبل استخدامها. على سبيل المثال ، لا يحتاج العميل إلى معلومات التوجيه باستخدام عنوان URL الأولي. بالإضافة إلى ذلك ، لا تحتاج المنافذ إلى إشعارات متنوعة حيث يمكن للعملاء الحصول على واجهة "مستمع" قياسية للإشعارات.

بالإضافة إلى ذلك ، مع عدد قليل من العمليات ، يمكن لـ REST التعامل مع العديد من الموارد ، مما يجعل من السهل البناء والتكيف. نأمل أن تزيل المدونة أي لبس حول REST API ، من تعريفها الأساسي لواجهة برمجة التطبيقات إلى كيفية عملها.

تعلم كيف Astera Centerprise يجعل تكامل REST API عملية بنقرة واحدة هنا.

Centerprise شعار مستخرج البيانات