يعد تبادل البيانات عبر منصات متعددة أكثر أهمية من أي وقت مضى في عصر التكامل. ضع في اعتبارك متجرًا على الإنترنت بدون عمليات تكامل. سيتعين على موقع الويب الخاص بك تطوير أنظمة لإدارة حسابات المستخدمين واشتراكات البريد الإلكتروني ومعالجة الدفع والشحن والمهام الأخرى بالإضافة إلى إدارة قوائم المنتجات. سيكون من الأكثر فعالية الاستعانة بمصادر خارجية لهذه الواجبات لمقدمين آخرين لأن هذا ليس خيارًا قابلاً للتطوير.
واجهات برمجة التطبيقات ، أو واجهات برمجة تطبيقات الويب ، هي ما تستخدمه البرامج للتواصل مع بعضها البعض. تقدم واجهات برمجة التطبيقات بروتوكولًا ثابتًا لتبادل البيانات بين برنامجين. بمساعدة واجهات برمجة تطبيقات الويب ، يمكن لمتجرك عبر الإنترنت التواصل مع برامج التسليم وتطبيقات العميل وتطبيقات الدفع وأي اتصالات أخرى مطلوبة.
هناك طرق مختلفة لإنشاء API ؛ ومع ذلك ، إذا كنت ترغب في إضافة اتصالات البرامج إلى خدماتك ، فهناك تقنية فريدة يجب أن تكون على دراية بها: خدمات الويب REST APIs. في هذه المقالة ، سنناقش أمثلة REST API ، وما هي REST API ، وكيف تعمل REST APIs ، وما هي واجهات برمجة تطبيقات REST المستخدمة ، والتاريخ ، وعناصرها ، وأكثر من ذلك.
ما هو بالضبط REST API؟
يعتبر نقل الحالة التمثيلية أو خدمات الويب REST APIs أكثر الممارسات القياسية لربط المكونات في أطر عمل الخدمات المصغرة لأنها توفر طريقة محمولة ومتعددة الاستخدامات لدمج التطبيقات. REST هو تصميم API شائع نستخدمه للتفاعل مع أصحاب المصلحة الداخليين والخارجيين بطريقة موحدة ويمكن التنبؤ بها.
يستخدم مستخدمو تطبيقات الويب بشكل متكرر خدمات الويب REST APIs للتواصل مع بعضهم البعض. على سبيل المثال ، الحصول على تفاصيل الحساب ومراجعتها في أحد برامج التواصل الاجتماعي . يمكن عرض متصفحات REST APIs على أنها بناء جملة الويب. يستخدم العملاء عبر الإنترنت واجهات برمجة تطبيقات الويب لتوفير وإدارة الوصول إلى العمليات الرقمية مع زيادة استخدام السحابة.
يعد تصميم واجهات برمجة تطبيقات الويب التي تمكّن العملاء من الاتصال بخدمات الويب الرقمية وإدارتها والتعامل معها ديناميكيًا في سياق متفرقة قرارًا معقولاً. تستخدم مواقع الويب مثل Google و eBay و Facebook و Amazon و Twitter خدمات الويب RESTful. يمكن لتطبيقات العميل الآن استخدام REST للوصول إلى خدمات الويب هذه.
تُفضل تقنية REST على التقنيات الأخرى ذات الصلة. وذلك لأن خدمات الويب REST تستهلك نطاقًا تردديًا أقل ، مما يجعلها مثالية للنشاط الفعال عبر الإنترنت. يمكن أيضًا تطوير خدمات الويب RESTful باستخدام لغات البرمجة مثل JavaScript أو Python.
كيف تعمل REST APIs؟
لمعرفة كيفية عمل REST APIs ، يجب علينا تحديد بعض المصطلحات الأساسية:
عميل
يشار إلى مستخدم API على أنه عميل. يرسل العميل استعلامات إلى واجهات برمجة تطبيقات الويب للحصول على البيانات أو تطبيق التعديلات على البرنامج. متصفح الإنترنت الخاص بك هو عميل. يتواصل مع واجهات برمجة تطبيقات الويب المختلفة للحصول على محتوى الصفحة. يتلقى جهاز الكمبيوتر الخاص بك المعلومات المطلوبة ، والتي يتم عرضها بعد ذلك على الشاشة.
فيما يلي أكثر طرق HTTP شيوعًا:
- استخدم طلب GET لإرجاع البيانات المطلوبة أو الموارد المطلوبة.
- استخدم طلب POST لإنشاء مورد جديد
- استخدم تعليمات PUT لإجراء تغييرات أو الاستمرار في تحديث مورد موجود
- استخدم الأمر DELETE للتخلص من أحد الموارد.
على سبيل المثال ، يمكن أن يكون طلب HTTP إلى واجهة برمجة تطبيقات Youtube مصدر طلب GET لفيديو معين أو منشور معين أو طلب POST لنشر صورة جديدة. يمكنك استخدام طريقة طلب POST لنشر مشاركات جديدة. في المقابل ، قد تستخدم منصة خدمات الويب الخاصة بالعميل التي تتكامل مع تنفيذ الرد التلقائي تعليمات PUT لتحديث الترحيب المخصص أو إزالته.
احصل على طلب
- التخزين المؤقت لطلب GET ممكن. يتضمن سجل المتصفح طلبات GET.
- يمكن وضع إشارة مرجعية على طلبات GET.
- لا تستخدم طلبات GET أبدًا أثناء العمل مع المواد الهامة.
- هناك قيود طول على طلبات GET.
- يتم إجراء استعلامات البيانات فقط عبر طلبات GET
طريقة POST
طلب POST هو طريقة نشر لإرسال المعلومات إلى خادم لإضافة الموارد أو تحديثها. يحتوي نص الطلب لطلب HTTP على البيانات التي يتم نشرها على جانب الخادم:
- يطلب POST طريقة النشر لا تدخل ذاكرة التخزين المؤقت أبدًا.
- لا يتم تخزين طلبات POST في محفوظات المتصفح.
- طلبات POST ليست مرجعية
هيئة الاستجابة
نص الاستجابة هو أحد العناصر المهمة في RESTful API. يتم تضمين البيانات المطلوبة في نص الاستجابة. قد تتضمن هيئة الاستجابة بيانات تتعلق بمنافذ منطق الإخراج والإخراج.
الموارد
أي بيانات يمكن أن توفرها واجهات برمجة تطبيقات الويب للمستخدم هي مورد. على سبيل المثال ، يمكن اعتبار فرد أو صفحة أو صورة أو ملاحظة كلها موارد في واجهة برمجة تطبيقات Facebook. معرف المورد هو مصطلح خاص يعطى لكل مورد.
قاعدة بيانات للانترنت
يستخدم البرنامج الذي يقبل هيئة طلب العميل خادم ويب يضم الموارد التي يطلبها المستهلك. يمكن للخادم التواصل مع العملاء من خلال واجهة برمجة التطبيقات (API) دون تقديم وصول فوري للعملاء إلى المعلومات المحفوظة في قواعد البيانات الخاصة به. عندما يصل المستخدم إلى خدمات الويب RESTful لتقديم نص الطلب ، يرسل الخادم تصويرًا طبيعيًا لحالة المورد إلى المستعرض.
يشير هذا إلى أن الخادم بطريقة ما لا يرسل المورد الدقيق إلى العميل ولكنه يعكس حالته ، أي حالة المورد في طابع زمني محدد. للمساعدة في الفهم ، يتم إرجاع الردود بتنسيق خفيف الوزن.
يستخدم JSON (JavaScript Object Notation) على نطاق واسع لأنه مقروء من قبل كل من الأشخاص والآلات ويتفوق في المساعدة على تعزيز إمكانية الوصول إلى الويب. يستخدم JSON بشكل أساسي لإرسال نص الطلب في تطبيقات الويب وتطبيقات العميل. إنه نموذج متوافق مع مجموعة متنوعة من الترميز. تتضمن تنسيقات بيانات API بخلاف JSON XML و YAML و CSV و HTML والنص العادي. يمكن لمستخدمي واجهات برمجة التطبيقات تحديد أي تنسيق بيانات يرغبون فيه باستخدام أنواع وسائط مخصصة.
تاريخ REST APIs
كان على العديد من المبرمجين العمل مع SOAP قبل REST لدمج واجهات برمجة التطبيقات. من المعروف أن بناء SOAP واستخدامه وتصحيحه كان من المهام الصعبة. لحسن الحظ ، تم تطوير REST من قبل فريق من المبرمجين تحت إشراف Roy Fielding ، لتغيير بيئة API إلى الأبد.
فيما يلي تسلسل زمني لتطوير REST APIs بمرور الوقت:
قبل REST
كتب المبرمجون يدويًا ملف XML يحتوي على استدعاء إجراء بعيد (RPC) داخل المحتوى لتوصيل واجهات برمجة تطبيقات الويب باستخدام SOAP. بعد ذلك ، ينشر المصممون حزمة SOAP الخاصة بهم إلى نقطة النهاية المحددة.
في عام 2000
اختار فريق من المبرمجين بقيادة Roy Fielding تطوير إطار عمل يمكّن أي خادم من الاتصال بأي خادم آخر. لقد وضع القيود على REST APIs. نظرًا لأن هذه الإرشادات عالمية ، فإن تطوير البرامج أسهل.
في العام 2002
طورت eBay واجهة برمجة تطبيقات RESTful الخاصة بها في عام 2002 ، وفتحت سوقها لأي موقع ويب قد يستفيد منها. لهذا السبب ، أصبح عملاق التجارة الإلكترونية الآخر ، أمازون ، مهتمًا به ، وفي عام 2002 ، أطلق RESTful API.
في العام 2004-2006
تم إطلاق خدمات الويب RESTful من Flickr في عام 2004 ، مما سمح للكتاب بإضافة الصور بسرعة إلى مواقعهم على الويب ومنشوراتهم على وسائل التواصل الاجتماعي. عندما لاحظ Twitter و Facebook عددًا كبيرًا من المبرمجين يقومون بمسح المواقع الإلكترونية وإنشاء واجهات برمجة تطبيقات "Frankenstein" ، كشف كلاهما عن واجهات برمجة التطبيقات الخاصة بهما بعد حوالي عامين.
في العام 2006 حتى الآن
خدمات الويب RESTful مقبولة الآن على نطاق واسع من قبل المبرمجين ، الذين يستخدمون خدمات الويب RESTful هذه لتحسين أداء تطبيقاتهم ومواقعهم. يعمل AppMaster على تسهيل التعاون وتسهيل إنشاء واجهات برمجة التطبيقات ، مما يتيح لك القيام بذلك بسرعة أكبر.
ما هي واجهات برمجة تطبيقات REST المستخدمة؟
تتمثل إحدى الفوائد الرئيسية لخدمات الويب RESTful في أنها توفر قدرًا كبيرًا من المرونة ، مما يسمح لك باستخدام واجهة برمجة تطبيقات RESTful هذه بشكل أكثر فعالية. فيما يلي بعض أمثلة REST API لما تُستخدم من أجله واجهات برمجة تطبيقات REST.
التطبيقات المستندة إلى السحابة
نظرًا لانعدام الجنسية لمكالماتها ، تعد واجهات برمجة تطبيقات REST مفيدة في التطبيقات السحابية. يمكن للوحدات عديمة الحالة إعادة التثبيت بسهولة والنمو لتلبية متطلبات السعة إذا حدث خطأ ما. يعد البرنامج الذي يجمع بين المكونات المحلية والمكونات المستندة إلى الإنترنت تطبيقًا سحابيًا. يستخدم هذا النموذج خوادم بعيدة يمكن الوصول إليها من خلال متصفح الويب وخدمات الويب المستمرة على الإنترنت لتنفيذ التعليمات.
الموقع التقليدي لمضيفي التطبيقات السحابية هو نظام كمبيوتر بعيد يديره مشغل شبكة الحوسبة السحابية لجهة خارجية. يعد البريد ومشاركة المستندات وتخزينها وإدخال الطلبات ومراقبة المخزون و Microsoft Word وإدارة علاقات العملاء ( CRM ) وجمع المعلومات والتمويل والمحاسبة أمثلة على الوظائف التي يتم تنفيذها باستخدام التطبيقات المستندة إلى مجموعة النظراء.
يمكن استخدام واجهات برمجة تطبيقات REST ( APIs ) لتوصيل مصادر المعلومات الخارجية وموارد التخزين. يمكن للمبرمجين جعل التطبيقات السحابية أصغر باستخدام واجهات برمجة تطبيقات REST لنقل البيانات إلى برامج أخرى للتعامل مع العمليات الحسابية أو تحليلها وإعادة النتائج إلى برنامج البرنامج. تعمل واجهات برمجة التطبيقات التي تم اختبارها على فرض التوحيد النشط ، والذي يمكنه تسريع الإنتاج وتحقيق نتائج حقيقية.
يعد محرر مستندات Google أو Office 365 أحد الأمثلة الرئيسية على تطبيق السحابة. كل ما تحتاجه لمحرّر مستندات Google أو Office 365 هو جهاز كمبيوتر يمكنه تشغيل محركات البحث وخدمات الويب عبر الإنترنت. توفر شبكات الكمبيوتر واجهة المستخدم والعمليات ، بما في ذلك تخزين المعلومات. يمكن لشركتك استضافة العديد من التطبيقات السحابية المتميزة باستخدام مضيفي التطبيقات السحابية.
خدمات سحابية
نظرًا لأنك تحتاج إلى إدارة كيفية معالجة عنوان URL للاتصال بمورد من خلال واجهة برمجة تطبيقات ، فإن واجهات برمجة تطبيقات REST مفيدة أيضًا لخدمات الويب السحابية. من المحتمل أن تصبح بنية خدمات الويب RESTful الآن قياسية في المستقبل بسبب التطبيقات السحابية. يستخدم المبرمجون خدمات الويب RESTful للاتصال بالخدمات السحابية باستخدام الإنترنت. ينشئ المطور كودًا يستخدم واجهة برمجة تطبيقات موفر الإنترنت ، ويعطي المدخلات والمتغيرات الضرورية ، ثم يتحقق من الإجابة للتأكد من أن الإجراء يعمل كما هو متوقع.
يمكن للمستخدمين النهائيين الوصول إلى تطبيقات العميل أو خدمات الويب التي تقدمها خدمات الويب السحابية ، مثل البنية التحتية الحاسوبية أو أنظمة التخزين أو أنظمة التتبع ، باستخدام خدمة سحابية مثل خدمات الويب RESTful. تحدد واجهات برمجة التطبيقات قدرات التطبيق وعملياته والتفاصيل المطلوبة لتنفيذها. للحفاظ على خصوصية العميل وأمانه ، غالبًا ما تعتمد واجهات برمجة التطبيقات على إمكانية التشغيل التفاعلي REST أو بروتوكول الوصول إلى الكائنات البسيط (SOAP) وآليات الأذونات مثل OAuth 2.0.
يشار إلى مجموعة متنوعة من خدمات الويب باسم "الخدمات السحابية" ويتم إتاحتها للشركات والمستهلكين عبر الإنترنت عند الطلب. تم إنشاء خدمات الويب هذه لتقديم وصول سريع وغير مكلف إلى الأدوات والتطبيقات دون الحاجة إلى أجهزة أو بنية أساسية. يستخدم معظم الموظفين خدمات الويب السحابية لكل شيء بدءًا من البريد الإلكتروني وحتى التعاون في المستندات.
استخدام الويب
يمكن الحصول على واجهات برمجة تطبيقات الويب هذه من مشروع ويب للمستخدم ، أو تطبيق iPhone ، أو جهاز إنترنت الأشياء ، أو Windows Mobile نظرًا لأن REST لا تعتمد على وظائف جانب العميل. يمكنك إنشاء بنية لعملك دون التقيد بإطار عمل محدد من جانب العميل.
مثال على واجهة برمجة تطبيقات REST
دعونا نناقش مثال REST API. انقر فوق الرابط أدناه لتطلب من Open Trivia Database استعلامًا استخباراتيًا عشوائيًا: تم استخدام خدمات الويب RESTful هذه لتوفير واجهة برمجة تطبيقات ويب عامة. سيعرض جهاز الكمبيوتر الخاص بك سؤال اختبار فردي وإجاباته بتنسيق JSON.
باستخدام أي متصفح HTTP ، مثل عنوان url ، قد تصدر الاستعلام التالي وتتلقى ردًا في نص الاستجابة: https://opentdb.com/api.php؟amount=1&category=18
ستحتوي هيئة الاستجابة لملف XML الخاص بخدمة الويب على جميع معلومات الموظف.
تحتوي جميع لغات البرمجة وأدوات المطورين المستخدمة على نطاق واسع على مكتبات عميل HTTP ، مثل الاسترداد في JavaScript و Node.js و Deno والحصول على محتويات الملف () في PHP. يمكن قراءة إجابة JSON واستخدامها لأنها مقروءة آليًا قبل عرضها بتنسيق HTML أو بنمط آخر.
واجهات برمجة تطبيقات الباقي و REST
بمرور الوقت ، تم تطوير العديد من طرق نقل البيانات. ربما تكون قد صادفت خيارات مثل CORBA أو SOAP أو XML-RPC. معظم إرشادات الرسائل الصارمة المتقدمة. حدد روي فيلدنج لأول مرة REST في عام 2000 ، وهو أكثر وضوحًا من الآخرين.
إنها مجموعة من الاقتراحات والقيود لخدمات الويب RESTful وليست قاعدة. تتكون هذه من القيود المعمارية التالية:
قسم العميل والخادم
يمكن للعملاء وخوادم الويب الاتصال في اتجاه واحد فقط بموجب بنية REST: يطلب العميل وحدة تحكم المجال ، ويستجيب جهاز التحكم أو الخادم للطلب. لا تستطيع خوادم الويب إرسال الطلبات ، ولا يستطيع العملاء الرد ؛ يبدأ المستهلك جميع الاتصالات.
تعمل خدمات الويب RESTful على إبقاء العملاء والخوادم معزولين عن طريق تسهيل التفاعل بينهم. يمكن أن تتطور أجهزة الكمبيوتر العميلة دون خوف من التأثير على استضافة أخرى ، ويمكن تغيير مواد الخادم دون التأثير على العملاء عن غير قصد.
واجهة موحدة
وفقًا لهذه الإستراتيجية ، يجب أن تلتزم جميع الاستفسارات وردود الفعل بإجراء proweb القياسي أو نمط رسائلهم. تم تطوير التطبيقات والخوادم بلغات برمجة مختلفة تعمل بشكل سيئ مع بعضها البعض باستخدام وسيط. الواجهة الموحدة هي لهجة يمكن لأي عميل استخدامها للتفاعل مع أي واجهات برمجة تطبيقات REST.
ستكون ترجمة الطلبات وردود الفعل بين التطبيقات ذات التفاعل الطبيعي ممكنة فقط. قد تتداخل الاختلافات الطفيفة مع المعلومات وتفقدها ، وسيتعين على الحلول ترقية إجراءات الطلب الخاصة بها عندما تقوم واجهات برمجة تطبيقات الويب بتعديل واجهات برمجة التطبيقات الخاصة بها. واجهة متسقة تقضي على هذا الاحتمال.
احصل على حق الوصول إلى https://www.googleapis.com/youtube/v3/channels؟
مثل جميع تطبيقات REST Client ، يتضمن هذا الاقتراح جزأين من البيانات. تقنية HTTP هي GET. يصف هذا الإجراء الذي يرغب العميل في اتخاذه بشأن الموارد. يمكن للمستخدم إنشاء أربع طرق HTTP أساسية:
HTTP ، أو Hyper-Text Transfer Protocol ، هي اللغة العامة لمعظم واجهات برمجة تطبيقات REST. لم يتم تصميم HTTP مع وضع REST في الاعتبار. بالإضافة إلى ذلك ، قبلت REST نقل البيانات هذا كمعيار لتطبيقات REST المدركة. لاستخدام HTTP مع واجهات برمجة تطبيقات REST ، يقدم العميل طلبًا بتنسيق قد تكون على دراية به. نداء إشارة الفيديو إلى YouTube API ، على سبيل المثال ، يبدو كالتالي:
- استخدم الأمر GET للحصول على مورد.
- استخدم الأمر POST لإنشاء مورد جديد
- استخدم تعليمات PUT لإجراء تغييرات أو الاستمرار في تحديث مورد موجود
- استخدم طلب الحذف للتخلص من أحد الموارد.
تحدد طرق HTTP الإجراء المطلوب اتخاذه بخصوص مورد معين. تُعرف طرق HTTP أيضًا باسم أفعال HTTB.
عنوان URL هو HTTP
معرف المورد الموحد ، أو URI ، الذي يحدد المورد المقصود موجود في عنوان URL. يعد عنوان URL أيضًا نقطة نهاية في هذا السيناريو لأنه المكان الذي تتواصل فيه RESTful API مع مستخدم الخدمة.
سلسلة الاستعلام: عنوان URL يتضمن سلسلة استعلام. يتم استخدام سلسلة الاستعلام لتحديد المعلمات ، والتي يتم إعطاء القيم لها.
بعد تلقي الالتماس والتحقق منه ، يقوم خادم الويب بإعادة البيانات على المورد المستهدف. عادة ، يتم إرجاع البيانات في بنية تعرف باسم JSON (JavaScript Object Notation). تقدم JSON جميع مكونات المورد بتنسيق محمول يمكن للبشر قراءته بسهولة.
مبادئ الواجهة الموحدة
يجب أن تتبع الواجهة الموحدة المعلمات التالية:
HATEOAS: الوسائط التشعبية كمحرك لحالة التطبيق
الوسائط التشعبية هي المحرك وراء خدمات الويب RESTful. يشير هذا إلى أن الوسائط التشعبية هي كل ما يريد العميل فهمه للتعرف على إجابة المزود.
- يجب توفير عنوان URI الأول لتطبيق العميل فقط إلى العميل. يجب أن يدفع تطبيق العميل جميع المواد والأنشطة الأخرى باستمرار باستخدام الارتباطات التشعبية.
- لا تتطلب خدمات الويب RESTful لغة استعلام الإدخال (IDL) ، والتي تختلف عن واجهات برمجة التطبيقات الأخرى
نوع الوسائط هو اسم لتنسيق بيانات التمثيل. يحدد نوع الوسائط تعريفًا يوضح كيفية معالجة الصورة. تبدو واجهة برمجة تطبيقات الويب التي تستخدم REST وكأنها نص تشعبي. يحمل كل عنصر بيانات يمكن تناوله موقعًا ، إما بشكل مباشر (مثل من خلال خصائص الارتباط والهوية) أو ضمنيًا (على سبيل المثال ، مشتق من هيكل وصف نوع الوسائط).
رسائل وصفية ذاتية
يجب أن يوفر كل اتصال بين جانب العميل وجانب الخادم بيانات كافية لتنفيذ الاتصال. وفقًا لذلك ، يحتاج الطلب من جانب العميل إلى جانب الخادم إلى تحديد المورد الذي يحاول الوصول إليه جنبًا إلى جنب مع أهدافه المحددة.
بالإضافة إلى ذلك ، يجب أن تكون صور الموارد ذاتية الوصف ؛ لا يتعين على المستخدم أن يكون على علم بما إذا كان المورد هو شخص أم قطعة من المعدات. بدلاً من ذلك ، يجب أن تستجيب باتباع نوع الوسائط المتصلة بالمساعدة.
لذلك ، بلا منازع ، سنطور العديد من أنواع الوسائط الفريدة ، غالبًا نوع وسائط واحد لكل مورد. يحدد كل شكل من أشكال الوسائط نموذجًا قياسيًا للإنتاج. على سبيل المثال ، تحدد HTML كيفية عرض النص التشعبي وكيف يتعامل المتصفح مع كل مكون.تحديد الموارد
يجب التعرف على الموارد المشار إليها في الاتصالات الخلفية بين العميل والخادم باستخدام الصور. يسمح التمسك بنظام معرف الموارد الموحد (URI) لهذا الغرض. بمعنى آخر ، قد يتضمن الاتصال من الخادم إلى العميل إصدار HTML من المستند وبعض المعلومات بدلاً من الملف الحقيقي من وحدة تخزين الخادم.
يمكن للمستهلك فهم إصدار HTML بسهولة لأنه يتبع نمط URI. يجب على العميل تعديل الموارد من خلال إعطاء الخادم وصفًا لكيفية ظهور المورد في النهاية. سيمكن هذا المستخدم من بناء الموارد واسترجاعها وتعديلها وإزالتها. إذا كان العميل لديه التفويض اللازم لتغيير البيانات ، فيجب على الخادم تلبية الاستعلام.
عديم الجنسية
مع RESTful API ، يجب أن تكون جميع طلبات العميل عابرة. ونتيجة لذلك ، فإن كل هيئة استعلام واستجابة تتضمن جميع البيانات المطلوبة لإبرام العقد ، مما يجعل كل اتصال مستقلًا. الخادم لا يتتبع طلبات HTTP السابقة ؛ إنه يتعامل مع كل طلب تم إجراؤه بواسطة العميل على أنه استعلام جديد تمامًا.
نظرًا لأن الخادم لا يضطر إلى أداء أي مهام إضافية للحصول على البيانات التاريخية ، فإن عمليات النقل عديمة الحالة تقلل بشكل كبير من مقدار التخزين اللازم للخادم وتزيد من احتمال قبول الاستجابة. يضمن هذا قابلية التوسع في هذه التفاعلات: لا يتعين على المبرمجين القلق بشأن استخدام المزيد من السعة التخزينية أو فرض ضرائب على الخادم عندما يتوسع برنامجهم ويصدر طلبات HTTP.
طبقات
لقد حددنا حتى الآن استعلامات واجهة برمجة تطبيقات الويب على أنها تبادل مباشر بين العميل والخادم ، على الرغم من أن هذا يبالغ في التبسيط قليلاً. بين هاتين المؤسستين ، غالبًا ما يكون هناك المزيد من الخوادم. توجد هذه الأنظمة الأساسية أو الطبقات لإدارة حركة المرور وتفريقها وإضافة الحماية وأداء العديد من المهام الحاسمة الأخرى.
وفقًا لهذا المفهوم ، يجب تنظيم الرسائل المرسلة بين المستخدم والخادم المستهدف ومعالجتها بطريقة مماثلة ، بغض النظر عن الطبقات الموجودة بينهما. يجب أن تكون الطبقات الإضافية جيدة مع تفاعلات العملاء. يمكن للمبرمجين الذين يلتزمون بهذه القاعدة تغيير أنظمة الخادم دون التأثير على عملية الطلب والاستجابة الأساسية.
قابل للتخزين المؤقت
يحدث التخزين المؤقت عندما يتصفح العميل موقع ويب عندما يتم حفظ المحتوى على جهاز العميل. يتم تحميل المواد المخزنة مؤقتًا بسرعة من الذاكرة الداخلية بدلاً من تنزيلها مرة أخرى من الخادم عندما يزور المستخدم ذلك الموقع لاحقًا. تستخدم معظم المواقع الكبيرة التخزين المؤقت لتقليل تحميل الصفحة مع الحفاظ على مساحة الخادم وعرض النطاق الترددي.
يتم أخذ التخزين المؤقت للبيانات في الاعتبار عند تطوير واجهات برمجة تطبيقات REST. يجب أن توضح الاستجابة التي يقدمها الخادم للعميل ما إذا كان يمكن تخزين المورد المحدد وإلى أي مدى.
في كود الطلب
عقيدة REST الأخيرة غير ضرورية. عند الطلب ، يمكن أن تتضمن استجابة واجهة برمجة التطبيقات كود برمجي ليستخدمه العملاء. لهذا السبب ، يمكن للعميل تنفيذ برنامج أو تطبيق العميل في الواجهة الخلفية الخاصة به.
تعتبر واجهة برمجة التطبيقات API RESTful إذا كانت تتوافق مع هذه المجموعة من الإرشادات. ومع ذلك ، فإن هذه الإرشادات تمنح المبرمجين الكثير من الحرية لتعديل ميزات واجهة برمجة تطبيقات RESTful الخاصة بهم. تختلف واجهات برمجة تطبيقات REST عن بروتوكول الوصول إلى الكائنات البسيط ، وهو أسلوب شائع آخر لواجهة برمجة تطبيقات الويب ، من حيث أنها أكثر مرونة (SOAP).
إجماع نقطة النهاية
ضع في اعتبارك نقاط النهاية هذه:
- / مستخدم / 123 \ ثانية
- / المستخدم / معرف / 123 \ s
- / user / 123 \ s / user / id / 123 \ s
- / المستخدم /؟ id = 123
كلها طرق مشروعة للعميل 123 لاسترداد البيانات. عندما تكون هناك إجراءات أكثر تعقيدًا ، يزداد عدد الاحتمالات. على سبيل المثال ، بترتيب عكسي يبدأ عند الإدخال 51 ، اعرض 10 أشخاص بأسماء عائلات تبدأ بالحرف "أ" وتعمل لصالح الشركة.
في النهاية ، لا يهم كيفية هيكلة عناوين URL ؛ التوحيد في جميع مسائل RESTful API الخاصة بك. في أنظمة البرامج الضخمة التي بها العديد من المبرمجين ، لا يمكن أن يكون ذلك سهلاً. لا يمكن تجنب تعديلات RESTful API ، ولكن يجب عدم رفض عناوين URL لنقطة النهاية مطلقًا لأن القيام بذلك سيؤدي إلى توقف التطبيقات التي تعتمد عليها عن العمل.
إصدار REST API
تعد واجهات برمجة التطبيقات لتعيين الإصدار ممارسة شائعة لمنع حالات عدم التوافق. كتوضيح ، /2.0/user/123 يستبدل / user / 123. يمكن أن تستمر كل من نقطتي النهاية القديمة والجديدة في العمل. وبالتالي ، فإن هذا يفرض الحاجة إلى الحفاظ على واجهات برمجة التطبيقات المهمة الماضية. يمكن في نهاية المطاف إيقاف الإصدارات السابقة ، ولكن يجب التفكير بعناية في الإجراء.
مصادقة REST API
يمكن لأي جهاز تنزيل quip دون إذن باستخدام واجهة برمجة تطبيقات الاستعلام. واجهات برمجة التطبيقات التي تقرأ المعلومات الخاصة أو تسمح بتحرير الاستعلامات وإزالتها لا تدعم هذا. يتم إرسال البرامج من جانب العميل داخل نفس المجال مثل خدمات الويب RESTful واستقبال ملفات تعريف الارتباط بنفس طريقة طلبات HTTP. (يرجى ملاحظة أنه يجب تحديد خيار إعادة تشغيل الامتيازات في المواقع السابقة لـ Fetch ().) يمكن التحقق من استعلام API لتأكيد تسجيل دخول المستخدم ولديه الأذونات المطلوبة.
مصادقة HTTP الأساسية : يجب أن تستخدم برامج الجهات الخارجية حلول موافقة مختلفة. بعض طرق المصادقة الشائعة هي التحقق الأساسي من:
- HTTP. اسم مستخدم مشفر باستخدام base64: يتم تقديم سلسلة كلمة المرور في حقل الاستعلام كجزء من رأس اعتماد HTTP.
- مفاتيح API: من خلال توفير مفتاح RESTful API الذي قد يكون له أذونات خاصة أو يكون مقصورًا على موقع واحد ، يتم توفير واجهة برمجة التطبيقات لتطبيقات الجهات الخارجية. تحتوي كل رسالة على المفتاح إما في سلسلة الاستعلام أو في رأس HTTP. (سلسلة الاستعلام هي أحد مكونات URL).
- OAuth: قبل إجراء أي طلبات ، يتم إرسال معرف العميل وربما سر العميل إلى خادم OAuth للحصول على بيانات اعتماد. حتى انتهاء صلاحيته ، يتم نقل هوية OAuth مع كل طلب واجهة برمجة تطبيقات.
- رموز الإنترنت في JSON (JWT): ينقل رأس الاستعلام ورأس الاستجابة بأمان بيانات اعتماد المستخدم الموقعة رقمياً. تمكن JWTs الخادم من تشفير امتيازات الوصول ، مما يلغي الحاجة إلى الاستعلام عن قاعدة بيانات أو استخدام آلية مصادقة أخرى.
سيؤثر سيناريو الاستخدام على كيفية مصادقة واجهة برمجة التطبيقات:
- في بعض الأحيان ، يتم التعامل مع برنامج تابع لجهة خارجية مثل أي عميل آخر قام بتسجيل الدخول بنفس الامتيازات والحقوق. على سبيل المثال ، قد توفر واجهة برمجة التطبيقات للخريطة برنامجًا يطلب تعليمات بين نقطتين. يجب أن تتحقق من أن البرنامج مستخدم شرعي ، ولكن ليس من الضروري التحقق من بيانات اعتماد العميل.
- في حالات أخرى ، يطلب برنامج الجهة الخارجية معلومات شخصية من مستخدم معين ، مثل محتوى البريد. يجب أن تتعرف واجهات برمجة تطبيقات REST على العميل وأذوناته ، لكن لا داعي للقلق بشأن برنامج الاستدعاء.
أمان واجهة برمجة تطبيقات REST
تضيف خدمات الويب RESTful طريقة أخرى للتفاعل مع برامجك والتأثير فيها. حتى إذا لم يكن مضيفك هدف قرصنة مرتفع ، يمكن لمستخدم يسيء التصرف إرسال مئات الطلبات في الثانية وإغلاقها. لا تغطي هذه المقالة الأمان ، ولكن تتضمن أفضل الإجراءات القياسية ما يلي:
استفد من HTTPS
استخدم آلية مصادقة قوية
يمكن استخدام CORS لتقييد مكالمات العملاء إلى مناطق معينة.
وفروا ضرورات القدرات - أي لا تفعلوا
إنشاء خيارات الحذف غير الضرورية ؛ تحقق من جميع عناوين URL الخاصة بنقطة النهاية ومعلومات الجسم.
قم بحظر الروابط من قطاعات أو عناوين IP غير محددة من خلال عدم إخضاع قسائم API في JavaScript من جانب العميل.
يتم حظر الحزم الكبيرة بشكل غير طبيعي.
فكر في قيود الأسعار ، حيث تقتصر الطلبات الواردة من عنوان IP نفسه أو بيانات اعتماد واجهة برمجة التطبيقات على عدد N من الاستعلامات في الدقيقة.
الاستجابة برمز حالة HTTP المناسب واستعلامات سجل رأس ذاكرة التخزين المؤقت والتحقيق غير الناجح
طلبات متعددة وبيانات غير ضرورية
نشر خدمات الويب RESTful له حدود. من المحتمل أن تحتوي الاستجابة على معلومات أكثر مما طلبت أو أن هناك عدة طلبات مطلوبة للحصول على جميع المعلومات. فكر في خدمات الويب RESTful التي تتيح للمستخدمين الوصول إلى معلومات المؤلف والكتاب ؛ يمكن للعميل:
- اطلب معلومات أول 10 كتب ، مدرجة بترتيب الشراء (البائع الأول أولاً). يتم تضمين مجموعة من الكتب ، مع معرف كل كاتب ، في الإجابة.
لاسترداد المعلومات لكل كاتب ، أنشئ ما يصل إلى 10 استعلامات / مؤلف / معرف.
يجب إنشاء استعلامات N API لكل استجابة للاستعلام الأصلي ، والتي تتميز بأنها "مشكلة N + 1".
إذا كان هذا موقفًا متكرر الاستخدام ، فقد يتم تعديل خدمات الويب RESTful لتشمل جميع معلومات الكاتب لكل كتاب أنتجه ، بما في ذلك الاسم والجنس والجنسية والسيرة الذاتية وما إلى ذلك. قد يتم توفير المزيد من المعلومات حول كتبهم السابقة ، على الرغم من أن القيام بذلك سيعزز بشكل كبير عبء الاستجابة. قد يتم تغيير API لجعل معلومات الكاتب اختيارية. تفاصيل المؤلف = كاملة لمنع الإجابات الكبيرة بلا داع. قد يكون العدد الهائل من الخيارات التي يجب على مصممي واجهة برمجة التطبيقات دعمها مربكًا.
تغليف
أنت الآن تماما الأمم المتحدةتعرّف على واجهات برمجة تطبيقات REST ، وكيفية عمل واجهات برمجة تطبيقات REST ، وأمثلة REST API ، وما هي واجهات برمجة تطبيقات REST المستخدمة ، والقيود المعمارية ، وموضوعات أخرى مغطاة في هذا البرنامج التعليمي. قد يجد المبرمجون أن التعلم عن واجهات برمجة التطبيقات أمر صعب ومخيف ، لكن منصة AppMaster التي لا تحتوي على كود قد أنشأت مكتبة REST APIs جديدة يمكن الوصول إليها حيث يمكنك تعميق وعيك بمجموعة من واجهات برمجة تطبيقات REST لدعم تطويرك المهني الإضافي.
في AppMaster ، نحاول زيادة إمكانية الوصول إلى واجهة برمجة التطبيقات وسهولة استخدامها. نريدك أن تتعلم ، وتجرب ، وتدرك فوائد استخدام برمجيات API في حياتك المهنية والشخصية. لمساعدتك في تصميم واجهات برمجة تطبيقات ويب أفضل بشكل أسرع ، يعمل AppMaster على تحسين التعاون وأتمتة كل مرحلة من دورة حياة API. استمر في إنشاء وتطوير وتوسيع فهمك لواجهات برمجة تطبيقات REST.
