إنشاء واجهة برمجة التطبيقات باستخدام Azure Functions

  • 3 دقائق

حان الوقت الآن لتُنشئ واجهة برمجة تطبيقات لتطبيق قائمة التسوق لديك.

دالات Azure

تتمثل إحدى أعظم مزايا Azure Static Web Apps في أنها تستضيف تطبيق الويب وواجهة برمجة التطبيقات الخاصة بك التي أُنشئت باستخدام Azure Functions معاً! توزع Azure Static Web Apps الأصول الثابتة لتطبيق الويب الخاص بك عالمياً وتستضيف واجهة برمجة التطبيقات الخاصة بك في Azure Functions. من خلال هذا الإعداد، يمكنك الحصول على التوفر والسرعة التي تأتي مع التوزيع العالمي لأصول تطبيقات الويب الخاصة بك.

ما لا تحصل عليه مهم أيضاً.

لا تحتاج إلى خادم كامل للواجهة الأمامية أو الخلفية لتكوينها وصيانتها. هذا هو المكان المناسب لـ Azure Static Web Apps: تتمتع بسهولة نشر التطبيق وواجهة برمجة التطبيقات الخاصة بك بأقل قدر من التكوين والصيانة.

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

تنشئ Azure Static Web Apps عنوان URL فريداً لموقعك، والذي يمكنك العثور عليه في علامة التبويب "Overview" في المدخل. تتوفر واجهة برمجة التطبيقات من خلال عنوان URL ذاته من خلال إلحاق /api بعنوان URL.

واجهة برمجة تطبيقات قائمة التسوق الخاصة بك

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

فيما يلي نقاط النهاية الأربع التي ستنشئها:

الأساليب نقاط نهاية المسار نقطة نهاية واجهة برمجة التطبيقات الكاملة
GET products api/products
POST products api/products
PUT products/:id api/products/:id
DELETE products/:id api/products/:id

لاحظ أن طلبات HTTP GET الخاصة بك ستُوجه إلى api/products. تقتصر بادئة api على نقاط نهاية واجهة برمجة التطبيقات الخاصة بك في التطبيق. يمكنك تحديد أي مسارات أخرى لتلائم احتياجات موقعك لكن api تُشير دائماً إلى تطبيق Azure Functions.

إنشاء واجهة برمجة تطبيقات لتطبيق الويب

حتى الآن كنت تستخدم إطار عمل للواجهة الأمامية. ستُضيف قريباً واجهة برمجة تطبيقات وتوصلها بتطبيق الواجهة الأمامية الخاص بك. يحتوي مستودعك على مجلد api-starter الذي يحتوي على مشروع Azure Functions غير المكتمل ونقاط نهاية HTTP لـ PUT وPOST وDELETE لمنتجاتك. تفتقد واجهة برمجة التطبيقات دالة HTTP GET. ستُكمل واجهة برمجة تطبيقات مشروع Azure Functions وتضيف الدالة المفقودة. بعد ذلك، ستوصل واجهة برمجة التطبيقات الخاصة بك بتطبيق ويب الواجهة الأمامية.

معاينة التغييرات التي طرأت على تطبيق الويب الخاص بك

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

بعد إجراء التغييرات، سترغب في رؤيتها وهي تعمل قبل أن تقرر دمج التغييرات. بمجرد إنشاء طلب سحب من فرعك الجديد إلى الفرع الرئيسي، يُنشئ إجراء GitHub تطبيقك وواجهة برمجة التطبيقات وينشرهما في معاينة عنوان URL. يتيح لك هذا ترك تطبيق الويب الخاص بك يعمل باستخدام Azure Static Web Apps، ولكن يمكنك أيضاً رؤية مثيل معاينة ثانٍ مع النتائج من طلب السحب الخاص بك.

التواصل بين تطبيق الويب الخاص بك وواجهة برمجة التطبيقات

عند تشغيل واجهة برمجة التطبيقات محلياً باستخدام Azure Functions، فهي تعمل على المنفذ 7071 افتراضياً. يعمل تطبيق الويب الخاص بك على منفذ محلي مختلف. عندما يحاول تطبيق الويب الخاص بك إجراء طلب HTTP من منفذه إلى منفذ واجهة برمجة التطبيقات 7071، يُعرف هذا باسم مشاركة الموارد عبر المصادر (CORS). سيحول المستعرض الخاص بك دون اكتمال طلب HTTP ما لم يسمح خادم واجهة برمجة التطبيقات بمتابعة الطلب.

لا داعي للقلق بشأن مشاركة الموارد عبر المصادر عند النشر في Azure Static Web Apps. ذلك لأن Azure Static Web Apps تقوم بتكوين تطبيقك تلقائياً حتى يتمكن من الاتصال بواجهة برمجة التطبيقات الخاصة بك على Azure باستخدام وكيل عكسي. الوكيل العكسي هو ما يسمح لتطبيق الويب وواجهة برمجة التطبيقات الخاصة بك بالظهور وكأنهما يأتيان من مجال الويب نفسه. لذلك عليك فقط إعداد مشاركة الموارد عبر المصادر عند التشغيل محلياً.

الخطوات التالية

أنت الآن جاهز لإنشاء واجهة برمجة التطبيقات الخاصة بك وتكوين نقاط نهاية HTTP لتطبيق قائمة التسوق الخاص بك.