دليل إعادة توجيه الربيع وقضايا السياسة ذات الصلة

ملخص

ستركز هذه المقالة على تنفيذ عمليات إعادة التوجيه في الربيع ومناقشة الأسباب الكامنة وراء كل استراتيجية.

لماذا إعادة التوجيه؟

دعونا أولاً نفكر في سبب حاجتك إلى إعادة توجيه في تطبيق الربيع الخاص بك.

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

شيء واحد يجب ملاحظة أن النمط النموذجي/إعادة التوجيه/الحصول على نمط لا يحل بشكل كاف قضية الالتزام المزدوجة - قد لا تزال مسألة تحديث الصفحة قبل اكتمال الالتزام الأولي قد تؤدي إلى التزام مزدوج.

إعادة توجيه باستخدام إعادة توجيه

لنبدأ بهذه الطريقة البسيطة - لنأخذ مثالًا مباشرة:

خلف RedirectView سوف يطلق HttpservletResponse.SendRedRist () - سيؤدي ذلك إعادة التوجيه الفعلي.

لاحظ كيف حقن الخصائص التي قمنا بإعادة توجيهها إلى الطريقة هنا - يقوم الإطار بهذا الجزء من العمل الثقيل ، مما يتيح لنا التفاعل مع هذه الخصائص.

نضيف سمة إلى نموذج إعادة توجيه النموذج - يعرضه كمعلمة استعلام HTTP. يحتوي النموذج على كائنات - عادة ما تكون سلاسل أو كائنات يمكن تحويلها إلى سلاسل.

الآن دعنا نختبر وظيفتنا إعادة التوجيه - استخدم أمرًا بسيطًا للمساعدة في ذلك:

ستكون النتيجة:

إعادة التوجيه باستخدام إعادة التوجيه: بادئة

تستخدم الطريقة السابقة RedirectView ، لأنها ليست مثالية لبعض الأسباب.

أولاً ، نحن الآن مقترن في API Spring لأننا نستخدم RedirectView مباشرة في الكود الخاص بنا.
ثانياً ، نحتاج إلى معرفة من البداية أنه عند تنفيذ تشغيل وحدة التحكم ، سيتم إعادة توجيه نتائجها دائمًا ، ولكن هذا ليس هو الحال دائمًا.

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

يبدو أن هذا:

عندما يتم إرجاع اسم العرض مع إعادة التوجيه: ، تعترف فئة urlbasedviewresolver (وجميع فئاته الفرعية) بأنها مؤشر خاص يجب إعادة توجيهه. سيتم التعامل مع بقية اسم العرض كعنوان URL إعادة توجيه.

هناك مكان يجب ملاحظته هنا - عندما نستخدم إعادة التوجيه:/إعادة توجيه المنطق المنطقي هنا ، فإننا نقوم بإعادة توجيه تتعلق بسياق servlet الحالي.

إذا كنت بحاجة إلى إعادة توجيه إلى عنوان URL المطلق ، فيمكننا استخدام اسم مثل هذا: Redirect: http: // localhost: 8080/spring-redirect/redirectedurl.

حتى الآن ، عندما ننفذ الأمر Curl:

سوف نحصل على إعادة توجيه على الفور:

إعادة التوجيه مع البادئة إلى الأمام

دعونا الآن نرى كيف نفعل شيئًا مختلفًا قليلاً - إعادة توجيه.

قبل النظر إلى الكود ، دعونا نلقي نظرة على ملخص سريع وعالي المستوى لدلالات التوجيه وإعادة التوجيه:

سوف يستجيب إعادة التوجيه بعنوان URL جديد يحتوي على رمز الاستجابة 302 ورأس الموقع ؛ ثم سيقوم المتصفح/العميل بتقديم طلب إلى عنوان URL الجديد مرة أخرى إلى الأمام تمامًا على جانب الخادم ؛ تقوم حاوية Servlet بإعادة توجيه نفس الطلب إلى عنوان URL المستهدف ؛ لا يلزم تغيير عنوان URL في المتصفح

الآن دعونا نلقي نظرة على الكود:

مثل إعادة التوجيه: ، إلى الأمام: سيتم تحليل البادئة بواسطة urlbasedViewResolver ودراساته الفرعية. داخليًا ، يقوم هذا بإنشاء عملية تشغيل داخلية requestDispatcher.forward () للعرض الجديد.

عندما ننفذ الأمر مع Curl:

سنحصل على HTTP 405 (غير مسموح به):

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

الخصائص التي تحتوي على إعادة توجيه

التالي - دعونا نلقي نظرة على خصائص المرور في إعادة توجيه - الاستفادة من إعادة توجيه التوجيه في الإطار:

كما ذكرنا سابقًا ، يمكننا إدراج كائنات الخصائص مباشرة في الطريقة - مما يجعل الآلية سهلة الاستخدام للغاية.

لاحظ أيضًا أننا نضيف أيضًا سمة فلاش - هذه خاصية لن تتم إضافتها إلى عنوان URL. يمكننا تحقيق هذه الخاصية - يمكننا لاحقًا استخدام modelattribute ("FlashAttribute") في طريقة الهدف النهائي المعاد توجيهها للوصول إلى سمة الفلاش:

لذا ، أكمل بنجاح - إذا كنت بحاجة إلى استخدام Curl لاختبار الوظيفة:

سيتم إعادة توجيهنا إلى الموقع الجديد:

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

تكوين آخر بدون البادئات

الآن دعنا نستكشف تكوينًا آخر - إعادة التوجيه بدون بادئات.

لتحقيق ذلك ، نحتاج إلى استخدام org.springframework.web.servlet.view.xmlviewresolver:

بدلاً من org.springframework.web.servlet.view.internalResourceViewResolver التي استخدمناها في تكويننا السابق:

نحتاج أيضًا إلى تحديد حبة إعادة تهيئة في التكوين:

الآن يمكننا الرجوع إلى هذه الفاصوليا الجديدة من خلال المعرف لتشغيل إعادة التوجيه:

لاختبار ذلك ، نستخدم الأمر Curl مرة أخرى:

ستكون النتيجة:

إعادة توجيه طلب طلب نشر HTTP

بالنسبة لحالات الاستخدام مثل المدفوعات المصرفية ، قد نحتاج إلى إعادة توجيه طلبات نشر HTTP. اعتمادًا على رمز حالة HTTP الذي تم إرجاعه ، يمكن إعادة توجيه طلب النشر إلى HTTP GET أو POST.

وفقًا لمرجع بروتوكول HTTP 1.1 ، فإن رموز الحالة 301 (تمت إزالتها بشكل دائم) و 302 (تم العثور عليها) تسمح بتغيير طريقة الطلب من المنشور للحصول على. تحدد المواصفات أيضًا رموز الحالة 307 (إعادة التوجيه المؤقت) و 308 (إعادة توجيه دائم) لا تسمح بتغيير طريقة الطلب من Post للحصول على.

الآن دعنا نلقي نظرة على رمز إعادة توجيه طلب النشر إلى طلب آخر:

الآن ، دعونا نستخدم الأمر Curl لاختبار المنشور الذي تم إعادة توجيهه:

يتم إعادة توجيهنا إلى عنوان الوجهة:

ختاماً

تقدم هذه المقالة ثلاث طرق مختلفة لتنفيذ عمليات إعادة التوجيه في فصل الربيع ، وكيفية التعامل مع سمات/تمريرها عند إجراء عمليات إعادة التوجيه هذه وكيفية التعامل مع إعادة توجيه طلبات نشر HTTP.

ما سبق هو دليل إعادة توجيه VSPRENG (إعادة التوجيه) وقضايا الإستراتيجية ذات الصلة التي قدمها لك المحرر. آمل أن يكون ذلك مفيدًا لك. إذا كان لديك أي أسئلة ، فيرجى ترك رسالة لي وسوف يرد المحرر إليك في الوقت المناسب. شكرا جزيلا لدعمكم لموقع wulin.com!