أساسيات REST و RESTful API تطوير

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

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

الراحة لمطوري الويب

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

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

API اختصار لتقف على واجهة برمجة التطبيقات ، والتي هي طرق ل التواصل مع المكتبات أو التطبيقات الأخرى. يحتوي Windows على واجهات برمجة تطبيقات متعددة ، كما يحتوي Twitter على واجهة برمجة تطبيقات ويب ، على الرغم من أنها تؤدي مهام مختلفة بأهداف مختلفة.

الجمع بين كل ذلك معا ، واجهات برمجة التطبيقات RESTful هي واجهات برمجة التطبيقات التي تتبع بنية REST.

ما هو بالضبط بنية REST?

هذا هو المكان الذي يصعب فيه وضع التفاصيل. ومع ذلك ، هناك بعض الثوابت المعمارية ، مثل:

• التناسق عبر API بالكامل
• وجود عديمي الجنسية, أي لا توجد جلسات من جانب الخادم
• استخدام رموز حالة HTTP حيثما كان ذلك مناسبا
• استخدام نقاط نهاية عنوان URL مع التسلسل الهرمي المنطقي
• الإصدار في عنوان URL وليس في رؤوس HTTP

لا توجد أي إرشادات محددة بشكل مفرط مثل مواصفات W3C HTML5 والتي يمكن أن تؤدي إلى الارتباك ، ومزيج من عدم اليقين حول مصطلحات REST.

أيضا ، القائمة أعلاه لا يجب اعتبار قواعد صارمة وسريعة, على الرغم من أنها صحيحة في معظم واجهات برمجة التطبيقات RESTful الحديثة.

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

كما قال فيناي ساهني, “واجهة برمجة التطبيقات هي واجهة المستخدم الخاصة بالمطور.” يجب أن يكون كل شيء سهل الاستخدام ، ويوفر تجربة مستخدم رائعة. تهدف واجهات برمجة التطبيقات البعيدة إلى القيام بذلك.

الوجبات السريعة الرئيسية لواجهات برمجة التطبيقات المريحة

هذه النصائح هي في سياق واجهات برمجة التطبيقات بدقة لتطبيقات الويب. هذا يعني ذاك HTTP هو شرط, وغالبا ما يعني ذلك يتم استضافة بيانات API على خادم خارجي. دعنا ندرس كيفية عمل واجهات برمجة التطبيقات (RESTful) على جانب مستخدم واجهة برمجة التطبيقات.

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

بشكل عام هناك أربعة أوامر اعتدت ان الوصول إلى واجهات برمجة التطبيقات:

1. احصل على لاسترداد كائن
2. بريد لإنشاء كائن جديد
3. ضع لتعديل أو استبدال كائن
4. حذف لإزالة كائن

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

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

لكن ليس هناك الكثير من واجهات برمجة التطبيقات (RESTful) حتى تذهب إلى هذا الحد. النظر في Pokéapi والتي هي قاعدة بيانات Pokémon API مجانا. إنه مفتوح للجمهور مع تحديد معدل مناسب (قصر المستخدمين على عدد معين من طلبات واجهة برمجة التطبيقات على مدار فترة زمنية) ، ولكن يسمح فقط احصل على طريقة للوصول إلى الموارد. قد يكون هذا بالعامية API للاستهلاك فقط.

أنواع العودة هي أيضا مهمة ، ويجب الحفاظ على التجانس لجميع الموارد. JSON هو نوع إرجاع شائع مع المواصفات عبر الإنترنت التي تشرح بنيات البيانات المناسبة.

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

الوصول إلى موارد API

واجهات برمجة التطبيقات العامة هي عادة يمكن الوصول إليها من عناوين الموقع مباشرة. هذا يعنى هيكل URL مهم, ويجب أن تستخدم فقط لطلبات API.

يمكن أن تشمل بعض عناوين المواقع دليل البادئة مثل / V2 / للحصول على نسخة محدثة 2 من API السابقة. يعد هذا أمرًا شائعًا للمطورين الذين لا يريدون خفض قيمة واجهة برمجة تطبيقات 1.x ، ولكن لا يزالون يرغبون في تقديم أحدث بنية.

لقد استمتعت حقا هذا المنصب تغطي هياكل URL الأساسية وأمثلة من الخدمات الأخرى.

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

قد يساعدك البحث عن الأمثلة عبر الإنترنت في فهم المفاهيم بشكل أوضح. لقد رأينا بالفعل Pokeapi ، ولكن هنا بعض الآخرين أمثلة API في العالم الحقيقي للاطلاع على:

• Reddit API
• واجهة برمجة تطبيقات جيثب
• فليكر API
• Pinterest API

بناء API الخاصة بك

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

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

ولكن دعونا نلقي نظرة على بعض المبادئ الأساسية العمارة API.

بناء نقاط النهاية

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

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

نقاش كبير هو المفرد مقابل الجمع الأسماء. إذا كنت تقوم بإنشاء واجهة برمجة تطبيقات Twitter ، فقد يكون لديك مجموعة الكائنات أولاً (على سبيل المثال tweet) ، ثم عنصر العنصر الثاني (بمعنى tweet ID).

 $ / tweet / 15032934882934 $ / tweet / 15032934882934 

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

تعيين نوع العودة

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

هناك الكثير مما يدخل في تطوير واجهة برمجة التطبيقات ، لذلك أوصي باللعب مع واجهات برمجة التطبيقات أولاً. وبهذه الطريقة يمكنك معرفة كيفية قيام المطورين الآخرين ببناء واجهات برمجة التطبيقات الخاصة بهم ، ونأمل أن تتعرف على المتطلبات النموذجية.

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

• موقع REST API التعليمي
• كتابة واجهة برمجة تطبيقات REST البسيطة
• بناء خدمة ويب مريحة

مزيد من الموارد

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

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

إذا كان هذا هو هدفك ، فيرجى مراعاة الموارد التالية للمساعدة في رحلتك.

كتب

• REST API Design Rulebook
• واجهات برمجة تطبيقات الويب المريحة
• راحة خدمات الويب كتاب الطبخ
• REST دون عائق: دليل لتصميم API مثالي

مقالات

• دليل المبتدئين إلى HTTP و REST
• إنشاء واجهة برمجة تطبيقات مريحة
• دليل الموارد تسمية مريحة
• إنشاء واجهة برمجة تطبيقات REST باستخدام حزمة مكدس MEAN