Giáo trình Spring Boot MVC và REST API · Chương 5/12: Biểu mẫu, validation và điều hướng · Bài 11/28 · Biên soạn tháng 10/2026.

Mục tiêu bài học

Tránh gửi lại biểu mẫu khi refresh, đưa thông báo qua redirect và dùng session đúng phạm vi.

Vì sao không render danh sách ngay sau POST?

Nếu POST tạo khóa học rồi trả trực tiếp HTML danh sách, URL và request cuối của trình duyệt vẫn là POST. Khi refresh, trình duyệt có thể hỏi gửi lại dữ liệu và tạo thêm một bản ghi. Post/Redirect/Get giải quyết luồng điều hướng này: xử lý POST thành công, trả redirect, rồi trình duyệt gửi GET tới trang kết quả.

Trong CourseWebController, khi lưu thành công, Controller trả redirect:/courses. Còn khi có lỗi validation, nó trả courses/form để giữ dữ liệu và lỗi của lần nhập. Hai trường hợp có chủ đích khác nhau, không phải mọi POST đều phải redirect bất kể kết quả.

flash.addFlashAttribute("message", "Đã thêm khóa học");
return "redirect:/courses";

<p class="message" th:if="${message}" th:text="${message}"></p>

Flash không giống query parameter

Flash attribute được chuyển tới request tiếp sau qua cơ chế flash map của Spring; theo cấu hình thông thường, nó dùng session trong thời gian ngắn. Nó không xuất hiện như message=… trên URL và không dành để giữ dữ liệu lâu dài. GET trang đích render thông báo, lần tải tiếp theo thông báo thường không còn.

Query parameter phù hợp để giữ bộ lọc có thể chia sẻ hoặc đánh dấu trang, như q và page. Flash phù hợp thông báo “đã lưu”. Không để mật khẩu hoặc dữ liệu nhạy cảm trong URL vì URL có thể xuất hiện trong lịch sử, log và liên kết chia sẻ.

Session có ích nhưng không phải database

Session có thể giữ trạng thái đăng nhập hoặc dữ liệu tạm theo người dùng. Không lưu entity JPA đang được quản lý hoặc cả danh sách khóa học vào session để né truy vấn; dữ liệu dễ cũ và làm tăng bộ nhớ. Nghiệp vụ cần lưu bền phải vào database và có cơ chế kiểm tra quyền mỗi lần truy cập.

Spring Security quản lý authentication trong phiên đăng nhập; không cần tự tạo session attribute isAdmin rồi kiểm tra rải rác. Khi triển khai nhiều instance, trạng thái session cần được tính đến qua chiến lược phân phối hoặc lưu session tập trung; một session trong bộ nhớ không tự chia sẻ giữa các container.

PRG không phải cơ chế chống ghi trùng toàn diện

PRG giúp refresh GET không lặp lại POST vừa rồi, nhưng không ngăn hai lần bấm nút nhanh, hai request mạng hoặc client retry. Với đơn hàng, thanh toán hay thao tác cần đúng một lần, phải bổ sung ràng buộc dữ liệu, khóa nghiệp vụ hoặc idempotency key phù hợp.

Thực hiện thử: tạo một khóa học, quan sát Network thấy POST rồi redirect và GET, bấm refresh ở trang danh sách và xác nhận số dòng không tăng. Kiểm thử MockMvc xác nhận redirect URL; một kiểm tra trình duyệt bổ sung giúp nhìn thấy hành vi của người dùng thật. Không chỉ dựa vào việc thông báo màu xanh xuất hiện.

Lỗi thường gặp và lưu ý

• Không dùng redirect để che lỗi validation rồi làm mất nội dung người dùng nhập.
• Không coi flash message hoặc biến session là bằng chứng thao tác database đã thành công; kết quả giao dịch mới quyết định.

Ghi nhớ

Dùng PRG cho POST thành công, flash cho thông báo ngắn và session cho trạng thái phù hợp theo người dùng.

Tài liệu đối chiếu

• Flash Attributes