مقدمة إلى Spring Boot وREST

ظلّت كتابة واجهة HTTP بلغة Java زمنًا طويلًا تمرينًا في التجميع والتركيب. كان عليك أن تختار حاوية servlets وتثبّتها، وتصف التطبيق في ملف web.xml، وتربط إطار عمل ويب، وتضيف إليه محوّل JSON، وتعلن مصدر بيانات، ثم تنتج ملف .war وتودعه في خادم تطبيقات يجب صيانته على حدة. كان أول {"message":"ok"} يصل بعد نصف يوم من أعمال السباكة، ولم تكن هذه السباكة تخص أحدًا: تُنسخ من مشروع إلى آخر ومعها أخطاؤها.

أزال Spring Boot هذا اليوم الضائع. لم يفعل ذلك باختراع إطار عمل جديد — فهو لا يزال Spring — بل بقلب عبء الإعداد: فبدلًا من أن تصف ما تريد تفعيله، تعلن ما تريد إنجازه، ويضبط الإطار قيمًا افتراضية معقولة يتركك تستبدل بها غيرها. لم يعد الخادم بيئةً تودع فيها التطبيق، بل أصبح تبعيةً من تبعيات التطبيق. وعاد المُخرَج النهائي أمرًا بسيطًا هو java -jar.

أما الكلمة الثانية في العنوان فهي أكثر تضليلًا من الأولى. لقد صار «REST» في الاستعمال الشائع مرادفًا لـ«JSON عبر HTTP». وهذا ليس الشيء نفسه. فواجهة تعرض POST /api/getUtilisateurParId وتردّ بـ200 OK مع {"erreur": "introuvable"} تعيد فعلًا JSON عبر HTTP، لكنها لا تحترم تقريبًا أيًّا من القيود التي تجعل REST مفيدًا. والفرق ليس نظريًا: فهو يحدد ما تستطيع ذاكرة التخزين المؤقت، أو الوكيل (proxy)، أو تطبيق الجوال، أو مكتبة HTTP أن تفعله بردودك دون أن تعرف شيئًا عن منطقك العملي.