إنشاء واجهات REST API باستخدام Spring Boot

يمكن كتابة متحكّم (Controller) في Spring Boot خلال دقائق معدودة. ولهذا السبب تشترك كثير من واجهات API في العيب نفسه: كُتبت بسرعة، وهي تعمل، وفي اليوم الذي يلزم فيه إضافة حقل داخلي إلى جدول ما، نكتشف أن تطبيق جوال نُشر في السنة الماضية سيستقبل هذا الحقل.

نقطة التحول في أي واجهة API لا تكون تقنية في الغالب، بل تعاقدية. فمنذ اللحظة التي يستهلك فيها عميل ما ردودكم، يصبح شكل هذه الردود التزامًا لا يمكنكم تعديله من طرف واحد. والسؤال الذي يحدد ما سيأتي بعده بسيط إذن: من يقرر شكل JSON؟ إذا كان الجواب «الجدول»، فكل قرار يتعلق بالمخطط يتحول إلى قرار يخص الـ API، يتخذه شخص لم يكن يفكر في ذلك أصلًا.

يبني هذا الدرس عمليات CRUD الكاملة لكتالوج biblio-api، ويضع في الطريق الحدّ الوحيد الذي يهم: النموذج المكشوف كائن مستقل، كُتب خصيصًا للعالم الخارجي، ومستقل عن النموذج المخزَّن. وكل ما عدا ذلك — رموز الحالة، والترقيم الصفحي، وإدارة الإصدارات — ينبع من هذا القرار.

نعمل هنا مع مستودع في الذاكرة؛ أما الحفظ الفعلي للبيانات فيأتي في الدرس التالي. وهذا يتيح لنا معالجة تصميم الـ API دون أن يشتت انتباهنا JPA.

المتحكّم وما يفعله Spring به

يجمع @RestController بين @Controller و@ResponseBody: كل قيمة تُعاد يتم تسلسلها (serialization) في جسم الاستجابة، دون المرور بمحرك عرض.