Trong phát triển web/app, validation thường bị xem là việc nhỏ: kiểm tra form có trống không, email có đúng định dạng không, số lượng có lớn hơn 0 không. Nhưng nếu làm hời hợt, validation có thể dẫn đến lỗi dữ liệu, trải nghiệm người dùng kém, thậm chí tạo lỗ hổng bảo mật. Một nguyên tắc quan trọng: validation không chỉ nằm ở frontend. Frontend validation giúp người dùng sửa lỗi nhanh hơn, nhưng backend validation mới là lớp bắt buộc để bảo vệ hệ thống. Người dùng có thể tắt JavaScript, gọi API trực tiếp bằng công cụ khác, hoặc chỉnh request trước khi gửi. Vì vậy, mọi dữ liệu đi vào backend đều nên được xem là chưa đáng tin cho đến khi được kiểm tra. Ví dụ thực tế: form tạo mã giảm giá Giả sử bạn có chức năng tạo mã giảm giá với các trường: - code: mã giảm giá - discountPercent: phần trăm giảm giá - startDate: ngày bắt đầu - endDate: ngày kết thúc - maxUses: số lượt sử dụng tối đa Một số rule nên có: - code không được rỗng, chỉ gồm chữ, số, dấu gạch ngang hoặc gạch dưới - discountPercent phải là số, lớn hơn 0 và nhỏ hơn hoặc bằng 100 - startDate và endDate phải là ngày hợp lệ - endDate phải sau startDate - maxUses phải là số nguyên dương - code không được trùng với mã đã tồn tại Điểm đáng chú ý là không phải rule nào cũng giống nhau. Có thể chia validation thành vài nhóm: 1. Validation định dạng Đây là các kiểm tra cơ bản như email đúng dạng, số điện thoại có độ dài hợp lý, ngày tháng hợp lệ, chuỗi không vượt quá số ký tự cho phép. Ví dụ: tên sản phẩm không nên dài 10.000 ký tự nếu giao diện chỉ hiển thị khoảng 100 ký tự. Giới hạn độ dài vừa giúp dữ liệu sạch hơn, vừa tránh một số vấn đề hiệu năng hoặc hiển thị. 2. Validation nghiệp vụ Đây là phần dễ bị bỏ sót nhất. Dữ liệu đúng định dạng chưa chắc đã hợp lệ về mặt nghiệp vụ. Ví dụ: - Không cho đặt lịch trong quá khứ - Không cho áp mã giảm giá đã hết hạn - Không cho người dùng rút số tiền lớn hơn số dư - Không cho hủy đơn hàng đã giao thành công Các rule này nên nằm ở backend, gần tầng xử lý nghiệp vụ, không nên chỉ đặt ở giao diện. 3. Validation phụ thuộc dữ liệu hiện có Một số kiểm tra cần truy vấn database, ví dụ: - Email đã tồn tại chưa - Mã đơn hàng có thuộc về người dùng hiện tại không - Sản phẩm còn hàng không - Coupon còn lượt sử dụng không Với loại validation này, cần chú ý đến race condition. Ví dụ hai người cùng đặt sản phẩm cuối cùng trong kho. Nếu chỉ kiểm tra “còn hàng” rồi sau đó mới trừ kho, có thể cả hai request đều vượt qua validation. Trong trường hợp này, cần kết hợp transaction, khóa dữ liệu hoặc cơ chế cập nhật có điều kiện ở database. Thông báo lỗi nên rõ ràng nhưng không tiết lộ quá nhiều Một lỗi validation tốt nên giúp người dùng biết cần sửa gì. Ví dụ: - “Email không hợp lệ” tốt hơn “Invalid input” - “Mật khẩu cần ít nhất 8 ký tự” tốt hơn “Password failed” Tuy nhiên, với các chức năng nhạy cảm như đăng nhập, quên mật khẩu, kiểm tra tài khoản tồn tại, không nên trả về thông tin quá cụ thể. Ví dụ thay vì nói “Email này chưa được đăng ký”, có thể dùng thông báo chung như “Thông tin đăng nhập không đúng” để tránh bị dò tài khoản. Nên chuẩn hóa cấu trúc lỗi API Nếu làm API cho web hoặc mobile app, nên thống nhất format lỗi validation. Ví dụ response có thể gồm: - mã lỗi tổng quát - thông điệp chung - danh sách lỗi theo từng field Điều này giúp frontend xử lý dễ hơn, đặc biệt khi một form có nhiều trường. Thay vì chỉ hiện một alert chung, giao diện có thể đánh dấu chính xác ô nào cần sửa. Đừng tự viết mọi thứ nếu framework đã hỗ trợ tốt Hầu hết framework phổ biến đều có thư viện validation hoặc schema validation. Dùng công cụ có sẵn giúp code nhất quán, dễ test và dễ tái sử dụng hơn. Điều quan trọng là cả team nên thống nhất cách viết rule, cách trả lỗi và vị trí đặt validation. Một số lời khuyên có thể áp dụng ngay: - Luôn validation ở backend, kể cả khi frontend đã kiểm tra rồi - Đặt giới hạn độ dài cho chuỗi nhập vào - Phân biệt lỗi định dạng và lỗi nghiệp vụ - Chuẩn hóa response lỗi để frontend dễ hiển thị - Không tin dữ liệu từ client, kể cả dữ liệu ẩn trong form - Với thao tác liên quan tiền, tồn kho, quyền truy cập, cần kiểm tra lại ở tầng nghiệp vụ - Viết test cho các rule quan trọng như thanh toán, phân quyền, giới hạn số lượng Validation tốt không chỉ là chặn dữ liệu sai. Nó giúp hệ thống dễ bảo trì hơn, giảm lỗi khó truy vết và tạo trải nghiệm rõ ràng hơn cho người dùng. Nếu làm đúng từ đầu, bạn sẽ tránh được rất nhiều lỗi phát sinh khi sản phẩm lớn dần.