في هذه المقالة ، سوف نستمر في تعريف أنفسنا بتطوير REST API وإلقاء نظرة على طريقة Code-First.
يعد تطوير واجهة برمجة تطبيقات REST جيدة أمرًا مهمًا للحصول على خدمات ميكروية جيدة. يركز الأسلوب Code-First على إنشاء عقد من التعليمات البرمجية. هل هذا هو أفضل نهج ممكن؟
سوف تتعلم
- ما هي طريقة Code-First لتطوير واجهة برمجة تطبيقات REST؟
- ما هي فوائد نهج المدونة الأولى؟
- ما هي عيوب نهج المدونة الأولى؟
- متى تستخدم نهج Code-First؟
REST API
هذه هي المقالة الرابعة في سلسلة من المقالات على REST API:
ما هو نهج الكود الأول؟
عندما تقوم بتطوير خدمة ما ، مثل واجهة برمجة تطبيقات REST أو SOAP API ، يمكنك اختيار واحد من طريقتين:
- الرمز أولاً وإنشاء عقد من التعليمات البرمجية
- العقد الأول وتطوير العقد القائم على الكود
لنبدأ بمثال سريع لـ Code First.
ربيع التمهيد رمز أول مثال API REST
نحن نعمل على تطوير خدمة ويب RESTful باستخدام Spring Boot Framework لإنشاء API. على سبيل المثال ، في API retrieveAllUsers () ، نفتح URI "
/ users " و
نعيد جميع المستخدمين (الموارد
/ المستخدمين ) ،
استدعاء طريقة الخدمة.
عندما نذهب إلى عنوان URL هذا ، نرجع جميع المستخدمين:
يتم تعريف أساليب الخدمة الأخرى بشكل مشابه ، ولكل منها URI خاص بها. في هذا المثال ، نأخذ الكود وننشئ الوثائق منه. توضح هذه الوثائق كيف يمكن للمستخدم استخدام الخدمة. للقيام بذلك ، نستخدم تنسيق وثائق Swagger:
Swagger يسمح لنا بإنشاء وثائق من التعليمات البرمجية. على سبيل المثال ، إليك ما تنشئه Swagger لطلب جميع المستخدمين:
يعرض نوع رسالة الاستجابة التي نتلقاها وحالة الاستجابة المصاحبة لها. يمكنك حتى الاتصال بهذه الخدمة من Swagger للحصول على إجابة:
يمكنك أيضًا إرسال طلب
POST إلى "
/ المستخدمين ":
سيخبرك Swagger بكيفية تنظيم رسالة الطلب وتحديد تنسيقات الحقول الفردية داخلها. سيخبرك أيضًا بنوع الرد الذي ستتلقاه ، إلى جانب رمز الاستجابة. ما يولد Swagger من رمز يسمى
العقد .
فوائد الكود الأول
المزايا الرئيسية لهذا النهج:
- العقود بأقل جهد ممكن : لا يتطلب إنشاء عقد مجهودًا إضافيًا. هذا مجرد نتيجة ثانوية لتطوير الخدمة ، حيث يمكن توليدها تلقائيًا من الكود.
- مزامنة الرمز والعقد : نظرًا لأن العقد يتم إنشاؤه من الكود ، تتم مزامنتهما دائمًا مع بعضهما البعض
عيوب الكود اولا
عيوب هذا النهج هي كما يلي:
لا تنمية موازية
لا يمكن أن يتطور منتج الخدمة ومستهلكو الخدمات بشكل متوازٍ. تحتاج أولاً إلى تطوير خدمة ، ثم إنشاء عقد ، وبعد ذلك فقط يمكنك كتابة رمز عميل يلتزم بالعقد. دون فهم العقد ، لا يمكن تطوير المستهلك.
لا هدف للفرق
نظرًا لأنه لا يمكن معرفة العقد قبل تطوير الخدمة ، فلا يوجد غرض للعديد من أصحاب المصلحة في التطوير. لذلك ، هناك كل فرصة لانحراف الاتجاهات وسيتم إجراء تغييرات غير ضرورية ، مما سيؤدي إلى تبديد الجهد.
لا يوجد توافق عبر النظام الأساسي
في بعض الأنظمة الأساسية القديمة ، ليس من السهل إنشاء عقد من التعليمات البرمجية. نتيجة لذلك ، غالبًا ما يحدث عدم التوافق بين الأنظمة الأساسية للعقود التي تم إنشاؤها.
في هذه المشكلة ، يوجد
فيديو للمؤلف.
ملخص
في هذه المقالة ، استكشفنا طريقة Code First لبناء واجهة برمجة تطبيقات REST. على الرغم من أن النهج القائم على الشفرة فعال من وجهة نظر المطور ، إلا أنه يواجه مشكلات خطيرة عندما يتعلق الأمر بالتطوير المشترك للمورد والمستهلك.
قراءة إضافية
تطوير واجهة برمجة التطبيقات: التصميم أولاً أو الرمز أولاً؟كيفية تطوير خدمة ويب مريحة في ASP.NET Web API