REST API WITH PYTHON PHP NODEJS GO DJANGO LARAVEL LUMEN Examples
1.0.0
الباقي اختصار لنقل الحالة التمثيلية . Restful API هو نمط معماري لواجهة برنامج التطبيق (API) التي تستخدم طلبات HTTP للوصول إلى البيانات وتغييرها. يمكن استخدام هذه البيانات للحصول على أنواع البيانات ووضعها ونشرها وحذفها ، والتي تشير إلى القراءة وتحديث وحذف العمليات المتعلقة بالموارد. لمزيد من التفاصيل
الوظائف الرئيسية المستخدمة في أي بنية قائمة على الراحة هي:
يجب أن يفي طلبك ببعض القيود أو المبادئ. دعنا نخوض تفاصيل حول هذه المبادئ.
هناك ستة مبادئ أرضية ، فيما يلي المبادئ التوجيهية الستة للراحة:
لا أساس لها: تحتوي الطلبات المرسلة من عميل إلى الخادم على جميع المعلومات اللازمة لفهمها تمامًا. يمكن أن يكون جزءًا من معلمات uri أو معلمات الاستعلام أو الجسم أو حتى الرؤوس. يتم استخدام URI لتحديد المورد بشكل فريد ويحمل الهيئة حالة المورد طلب. بمجرد الانتهاء من المعالجة بواسطة الخادم ، يتم إرسال استجابة مناسبة إلى العميل من خلال الرؤوس أو الحالة أو هيئة الاستجابة.
خادم العميل: يحتوي على واجهة موحدة تفصل العملاء عن الخوادم. يساعد فصل المخاوف في تحسين قابلية نقل واجهة المستخدم عبر منصات متعددة وكذلك تعزيز قابلية التوسع لمكونات الخادم.
واجهة موحدة: للحصول على التوحيد خلال التطبيق ، حددت REST أربعة قيود واجهة هي:
Resource identification
Resource Manipulation using representations
Self-descriptive messages
Hypermedia as the engine of application state
قابلة للتخزين المؤقت: من أجل توفير أداء أفضل ، غالبًا ما تكون التطبيقات قابلة للتخطيط. يتم ذلك عن طريق وضع علامة على الاستجابة من الخادم على أنه قابل للتخطيط أو غير قابل للتخطيط إما ضمنيًا أو صريحًا. إذا تم تعريف الاستجابة على أنها قابلة للتخطيط ، فيمكن أن يعيد ذاكرة التخزين المؤقت للعميل إعادة استخدام بيانات الاستجابة للاستجابات المكافئة في المستقبل. كما أنه يساعد في منع إعادة استخدام البيانات التي لا معنى لها.
نظام الطبقات: تتيح بنية النظام ذات الطبقات للتطبيق أن يكون أكثر استقرارًا عن طريق الحد من سلوك المكون. تتيح هذه البنية موازنة التحميل وتوفر ذاكرة التخزين المؤقت المشتركة لتعزيز قابلية التوسع. تساعد الهندسة المعمارية ذات الطبقات أيضًا في تعزيز أمان التطبيق حيث لا يمكن للمكونات في كل طبقة التفاعل إلى ما وراء الطبقة المباشرة التالية.
رمز عند الطلب: رمز عند الطلب هو قيد اختياري ويستخدم على أقل تقدير. يسمح بتنزيل رمز أو تطبيقات العملاء وتمديده عبر الواجهة المراد استخدامها داخل التطبيق. في جوهرها ، يبسط العملاء عن طريق إنشاء تطبيق ذكي لا يعتمد على بنية الكود الخاصة به.
الآن بعد أن عرفت ما هي واجهة برمجة تطبيقات REST وما كل ما تحتاج إلى الذهن من أجل تقديم تطبيق فعال ، دعنا نتعمق بشكل أعمق ونرى عملية بناء API باستخدام جميع تقنيات Trending و FrameWrks.
يقدم بروتوكول الوصول إلى الكائن البسيط (SOAP) طرقًا مختلفة لاستدعاء خدمة الويب. REST هو نمط معماري ، بينما يحدد SOAP مواصفات بروتوكول الاتصالات القياسية لتبادل الرسائل المستندة إلى XML. يمكن لتطبيقات REST استخدام الصابون.
خدمات الويب المريحة عديمة الجنسية. يكون التنفيذ القائم على الراحة بسيطًا مقارنة بالصابون ، ولكن يجب على المستخدمين فهم السياق والمحتوى الذي يتم تمريره ، حيث لا توجد مجموعة قياسية من القواعد لوصف واجهة خدمات الويب REST. تعد خدمات REST مفيدة لأجهزة الملف الشخصي المقيد ، مثل الهاتف المحمول ، وسهلة الاندماج مع مواقع الويب الحالية.
يتطلب SOAP رمز السباكة أقل يعني رمز البنية التحتية منخفضة المستوى والذي يربط وحدات الرمز الرئيسية معًا من تصميم خدمات REST. تصف لغة وصف خدمات الويب مجموعة من القواعد المشتركة لتحديد الرسائل والروابط والعمليات وموقع الخدمة. تعد خدمات الويب SOAP مفيدة للمعالجة والاستدعاء غير المتزامن.
هذه بعض النقاط التي عليك التفكير فيها عند تطوير API REST:
ستعمل حمولة كبيرة للغاية لبيانات الاستجابة على إبطاء إكمال الطلب ، ومكالمات الخدمة الأخرى ، وفي التأثير على الأداء. كما تعلمون ، الآن بعد أن نعيد جميع الطلبات للعميل بدلاً من طلبهم الحالي فقط ، سيتعين علينا التعامل مع بعض عمليات تكسير الأداء.
يمكننا استخدام GZip Compression لتقليل حجم الحمولة النافعة. هذا يقلل من حجم تنزيل ردنا على تطبيق الويب (جانب العميل) ، وكذلك زيادة سرعة التحميل ، أو إنشاء بعض الكيان (الطلبات). يمكننا استخدام Deflate compression على واجهة برمجة تطبيقات الويب. أو يمكننا تحديث رأس القبول-encodingRequest إلى GZIP .
يعتبر التخزين المؤقت أحد أسهل الطرق لتحسين أداء واجهة برمجة التطبيقات. إذا كانت لدينا طلبات تعيد الاستجابة نفسها بشكل متكرر ، فإن الإصدار المخبوق من هذه الاستجابة يساعد على تجنب استفسارات مكالمات/قواعد البيانات الإضافية . ستحتاج إلى التأكد من استخدام التخزين المؤقت لإبطال البيانات بشكل دوري في ذاكرة التخزين المؤقت ، خاصةً عند حدوث تحديثات بيانات جديدة.
دعنا نقول أن عملائنا يريد تقديم طلب لجزء تلقائي ، وينادي تطبيقنا ببعض واجهة برمجة تطبيقات قطع غيار السيارات لجلب سعر الجزء. نظرًا لأن الاستجابة (سعر الجزء) تتغير مرة واحدة فقط كل أسبوع (@ 1:00 صباحًا) ، يمكننا تخزين استجابة لبقية الوقت حتى ذلك الحين. هذا يوفرنا من إجراء مكالمة جديدة في كل مرة لإرجاع سعر الجزء نفسه. حالة مماثلة يمكنك استخدام ذاكرة التخزين المؤقت لتجنب المكالمات أو الطلبات الإضافية.
ستؤدي الشبكة البطيئة إلى تدهور أداء واجهة برمجة التطبيقات الأكثر تصنيفًا بشكل قوي. يمكن أن تسبب الشبكات غير الموثوقة في وقت التوقف ، مما قد يتسبب في انتهاك مؤسستك من SLAs وشروط الخدمة والوعود التي قد تكون قد قطعتها لعملائك. من المهم الاستثمار في البنية التحتية للشبكة المناسبة ، حتى نتمكن من الحفاظ على المستوى المطلوب من الأداء. يمكن تحقيق ذلك من خلال الاستفادة من وشراء الموارد السحابية والبنية التحتية الكافية (example: in AWS, allocate the proper # of EC2 instances, use a Network Load Balancer) . أيضًا ، إذا كان لديك كمية كبيرة من عمليات الخلفية ، فقم بتشغيلها على مؤشرات ترابط منفصلة لتجنب طلبات حظر. يمكنك أيضًا استخدام المرايا ، وشبكات توصيل المحتوى (CDNs) مثل CloudFront لخدمة الطلبات بشكل أسرع حول أجزاء مختلفة من العالم.
يمكن أن يكون لديك موقف تعاني فيه واجهة برمجة التطبيقات الخاصة بك من هجوم DDOs الذي يمكن أن يكون إما خبيثًا ومتعمدًا ، أو غير مقصود عندما يتصل مهندس واجهة برمجة التطبيقات بالتنفيذ على حلقة من بعض التطبيقات المحلية. يمكنك تجنب ذلك عن طريق قياس المعاملات ، monitoring the number of how many transactions occur per IP Address, or per SSO/JWT Token (if the customer/calling app is authorized before calling the API) .
تساعد هذه الطريقة التي تحدها في الحد من الطلبات المفرطة التي من شأنها إبطاء واجهة برمجة التطبيقات ، وتساعد على التعامل مع المكالمات/عمليات الإعدام العرضية ، ومراقبة النشاط الضار المحتمل وتحديدها بشكل استباقي.
إنه اعتقاد خاطئ شائع بين المهندسين الذين يضعون وعمليات التصحيح نفس النتيجة. فهي متشابهة في تحديث الموارد ، لكن كل منها يقوم بالتحديثات بشكل مختلف. ضع موارد تحديث العمليات عن طريق إرسال تحديثات إلى المورد بأكمله. تطبق عمليات التصحيح تحديثات جزئية على الموارد التي تحتاج إلى تحديث فقط. ناتجة عن مكالمات INPatch التي تنتج حمولات أصغر ، وتحسين الأداء على نطاق واسع.
Pro-Tip: Even though PATCH calls can limit the request size, you should note that it is not Idempotent.
Meaning, it is possible that a PATCHcan yield different results with a series of multiple calls.
So, you should carefully and deliberately consider your application for using PATCH requests,
and make sure that they are idempotently implemented if needed. If not, use PUT requests.
ربما تكون هذه واحدة من أهم النصائح التي ستقرأها هنا. إذا كان هناك شيء واحد يجب أن تتعلمه من هذا الريبو ، فيجب أن يكون هذا! لا مفاوضات على هذا واحد.
إن وجود سجلات ومراقبة وتنبيه يساعد المهندسين على تشخيص المشكلات ومعالجتها قبل أن تصبح مشاكل . العديد من واجهات برمجة التطبيقات (express/revonder java ، go) لها نقاط نهاية محددة مسبقًا لتقييم أشياء مثل:
`/health`
`/metrics`
إذا لم تكن قد تم تمكين تسجيل الدخول ، وكانت هناك مشكلة محتملة ، فلن تتمكن من تتبع الأصل ، أو حيث تحدث المشكلة في طلب معين.
إذا لم يكن لديك تمكين المراقبة ، فلن تعرف من منظور تحليلي عدد المرات التي تحدث فيها بعض المشكلات أو الأخطاء. والتي ستمنعك بعد ذلك من التفكير في الحلول الممكنة.
و ... إذا لم تكن قد تم تمكين التنبيه ، فلن تعرف ما إذا كانت هناك مشكلة ، إلى أن يقوم العميل (أو الأسوأ ، العملاء) بالإبلاغ عنها.
يساعد ترقيم الصفحات في إنشاء دلاء من المحتوى من استجابات متعددة . يساعد هذا النوع من التحسين في تحسين الاستجابات مع الحفاظ على البيانات التي يتم نقلها/عرضها إلى العميل. يمكنك توحيد الاستجابات وتصنيفها والحد منها التي تساعد على تقليل تعقيد النتائج ، وتحسين تجربة العملاء الإجمالية من خلال توفير الاستجابة/النتائج فقط لما طلبه العميل.
نحن نعلم أن واجهات برمجة التطبيقات مذهلة ، ويمكن أن تكون قوية للغاية في تزويد الأعمال والعملاء بتجربة رائعة ، إذا تم تحسينها بشكل صحيح وتعزيز الأداء. تتطور متطلبات العمل وتوقعات العملاء دائمًا مع مرور الوقت. وبصفتنا مهندسين مسؤولين ، فإن الأمر متروك لنا في تحديد كيفية بناء واجهات برمجة التطبيقات الخاصة بنا بطريقة أداء ، والتي يمكن أن تساعدنا على تحقيق أهدافنا وتجاوزها.
هذه النصائح هي مجرد غيض من الجبل الجليدي ، وتطبق على جميع واجهات برمجة التطبيقات في بيئة عامة. اعتمادًا على واجهة برمجة التطبيقات الخاصة بك وحالة الاستخدام ، ما هي الخدمات التي تتفاعل معها ، وعدد المرات التي يتم استدعاؤها ، من حيث يتم استدعاؤها ، وما إلى ذلك. قد تضطر إلى تنفيذ هذه النصائح بطرق مختلفة.
REST API مع Laravel - جواز السفر
REST API مع PHP - عفوًا
REST API مع Python - Flask
REST API مع Python - Django - RestRamework
REST API مع GO - MUX
REST API مع GO - الجن
REST API مع Nodejs - Express - Basic
REST API مع Nodejs - Express- JWT - Sequellze - Advance
من السهل جدًا إنشاء واجهة برمجة تطبيقات REST في غضون بضع دقائق ، يمكنك اختيار أي من قاعدة التعليمات البرمجية أعلاه وفقًا لتفضيلات لغتك وإطارك واتبع التعليمات لإنشاء API REST.
ترميز سعيد؟
LinkedIn: https://www.linkedin.com/in/the-startup-cto/
المتوسط: https://apige.medium.com/
Twitter: https://twitter.com/htngapi
