Trong code hiện tại, cơ chế “chuyển đổi URI” không phải là một tầng rewrite request ở web server, cũng không phải bộ router tự động đổi URL khi người dùng truy cập. Nó là một cơ chế hậu xử lý URI theo cấu hình, được dùng chủ yếu khi hệ thống cần xuất ra liên kết public, đặc biệt là cho sitemap.

Bài toán mà cơ chế này giải quyết

Trong nhiều hệ thống CMS hoặc e-commerce, dữ liệu liên kết thường được lưu theo một dạng ổn định, ví dụ như URI gốc, mã định danh, hoặc đường dẫn kỹ thuật. Nhưng URI cần xuất ra bên ngoài lại có thể thay đổi theo quy ước SEO, slug, loại nội dung, hoặc cấu trúc URL của từng dự án.
Thay vì hard-code các quy tắc này trong Java, hệ thống chọn một hướng linh hoạt hơn:
  • lưu URI gốc trong bản ghi liên kết,
  • cho phép cấu hình một đoạn script để chuyển URI,
  • áp dụng script này đúng lúc hệ thống cần sinh ra URI public.
Điều đó giúp thay đổi cấu trúc URL mà không phải sửa code lõi.

Kiến trúc tổng quát

Cơ chế này xoay quanh 4 phần:
  • kho dữ liệu liên kết, nơi giữ URI gốc và metadata của từng link,
  • khu vực cấu hình admin, nơi người vận hành nhập script chuyển đổi URI,
  • bộ chuyển đổi URI, nơi thực thi script trên từng bản ghi liên kết,
  • đầu ra tiêu thụ URI đã chuyển đổi, hiện tại nổi bật nhất là sitemap XML.
Điểm đáng chú ý là phần web runtime trong module này chủ yếu làm nhiệm vụ phục vụ file sitemap và nội dung robots.txt. Nó không cho thấy logic bắt request rồi tự động map URI đã chuyển đổi quay ngược về tài nguyên gốc.

Cách một URI được chuyển đổi

Luồng hoạt động thực tế có thể tóm gọn như sau:
flowchart TD
    A[Bản ghi liên kết trong hệ thống] --> B[Đọc script chuyển đổi từ cấu hình]
    B --> C[Đưa dữ liệu link vào môi trường script]
    C --> D[Script trả về URI mới]
    D --> E[Sử dụng URI mới khi dựng sitemap hoặc dữ liệu hiển thị]
    D --> F[Nếu script rỗng hoặc không trả kết quả thì dùng URI gốc]
Về mặt nguyên lý:
  1. Hệ thống lấy danh sách liên kết từ nguồn dữ liệu.
  2. Hệ thống đọc script chuyển đổi URI đã lưu trong phần cài đặt.
  3. Với mỗi liên kết, hệ thống tạo một ngữ cảnh thực thi script.
  4. Bản ghi liên kết được đưa vào script như dữ liệu đầu vào.
  5. Script có thể đọc thông tin của liên kết và tra cứu thêm dữ liệu liên quan.
  6. Nếu script trả về một chuỗi URI mới, URI đó sẽ được dùng làm đầu ra.
  7. Nếu script trống, trả về null/không có giá trị, hệ thống giữ nguyên URI gốc.
Đây là một cơ chế “transform at read/export time”, không phải “rewrite at request time”.

Dữ liệu đầu vào của script

Từ implementation có thể thấy script được cấp ít nhất một đối tượng liên kết làm đầu vào. Bản ghi này mang các thông tin kiểu như:
  • loại liên kết,
  • URI gốc,
  • loại nguồn dữ liệu,
  • ID nguồn dữ liệu,
  • thời gian cập nhật,
  • và một số metadata liên quan như ảnh mô tả.
Ngoài dữ liệu link, môi trường script còn được gắn thêm một số dịch vụ tra cứu nghiệp vụ. Điều này cho phép script không chỉ sửa chuỗi URI đơn thuần, mà còn có thể:
  • tra slug của nội dung,
  • tra thông tin bài viết,
  • tra thông tin sản phẩm,
  • từ đó dựng ra một URL thân thiện hơn.
Ví dụ về mặt ý tưởng, script có thể đi theo hướng: 
if (link thuộc nhóm bài viết) {
  lấy slug hiện tại của bài viết
  return "/bai-viet/" + slug
}
return link.linkUri
Ý nghĩa ở đây là URI public có thể được tính động từ dữ liệu nghiệp vụ, thay vì phụ thuộc hoàn toàn vào giá trị linkUri ban đầu.

Hệ thống áp dụng URI đã chuyển đổi ở đâu

Theo code hiện tại, nơi áp dụng rõ nhất là luồng sinh sitemap.
Khi hệ thống dựng danh sách URL cho sitemap:
  • nó lấy các liên kết theo từng nhóm,
  • chạy bộ chuyển đổi URI cho từng link,
  • ghép URI sau chuyển đổi vào dữ liệu response,
  • rồi serialize thành XML sitemap.
Sau bước này, mỗi thẻ <loc> trong sitemap sẽ chứa URI public đã được chuyển đổi, không nhất thiết là URI gốc đang lưu trong bản ghi.
Ngoài sitemap, cùng cơ chế đó cũng được dùng ở lớp dữ liệu admin khi cần dựng danh sách link phục vụ hiển thị/xuất dữ liệu.

Vì sao thiết kế này hữu ích

Cách làm này có vài lợi ích rất thực dụng:
  • Tách quy tắc SEO khỏi code lõi.
  • Có thể đổi cấu trúc URL theo từng dự án hoặc từng giai đoạn.
  • Không cần deploy lại toàn bộ ứng dụng chỉ để đổi pattern URI.
  • Dễ mở rộng khi URI phụ thuộc vào slug hoặc dữ liệu nghiệp vụ khác.
  • URI xuất ra luôn được tính từ trạng thái dữ liệu mới nhất.
Nói ngắn gọn, đây là một thiết kế thiên về cấu hình động và khả năng thích nghi.

Cơ chế kiểm tra an toàn

Trước khi lưu cấu hình mới, hệ thống có một bước kiểm tra script:
  • tạo một bản ghi liên kết mẫu,
  • chạy thử script trên bản ghi đó,
  • nếu script ném lỗi thì từ chối lưu cấu hình.
Điều này không đảm bảo script đúng hoàn toàn với mọi dữ liệu thật, nhưng giúp chặn các lỗi cú pháp hoặc lỗi runtime cơ bản ngay từ màn hình cấu hình.
Ngoài ra, nếu script hợp lệ nhưng không trả về giá trị, hệ thống sẽ quay về dùng URI gốc. Đây là một cơ chế fallback khá an toàn.

Điều hệ thống hiện tại không làm

Đây là phần rất quan trọng nếu nhìn từ góc độ kiến trúc.
Từ source code hiện có, có thể kết luận rằng module này:
  • có phục vụ robots.txt,
  • có phục vụ các file sitemap đã sinh ra,
  • có chuyển đổi URI khi xuất dữ liệu sitemap.
Nhưng module này không cho thấy:
  • cơ chế bắt mọi request public rồi tự resolve URI đã chuyển đổi,
  • cơ chế redirect từ URI cũ sang URI mới,
  • cơ chế đồng bộ ngược từ URI đã chuyển đổi về routing nội dung.
Nói cách khác, chuyển đổi URI ở đây là một cơ chế sinh URL đầu ra, chưa phải một hệ thống URL rewriting đầy đủ cho request runtime.

Giới hạn cần lưu ý

Thiết kế này linh hoạt, nhưng cũng có vài giới hạn tự nhiên:
  • Logic URI nằm trong script nên khó kiểm soát hơn code typed.
  • Nếu script phụ thuộc tra cứu dữ liệu ngoài, chi phí tính toán sẽ tăng theo số lượng link.
  • Việc validate hiện tại là kiểm tra bằng dữ liệu mẫu, chưa phải test toàn diện.
  • Nếu nhiều nơi cùng cần “URI public chuẩn”, cần đảm bảo tất cả đều đi qua cùng bộ chuyển đổi để tránh lệch dữ liệu.
Vì vậy, về lâu dài, hệ thống này phù hợp nhất khi xem script như lớp quy tắc trình bày URL, còn quy tắc routing thật sự nên được quản lý ở một tầng riêng nếu sản phẩm cần URL runtime phức tạp.

Kết luận

Nguyên lý hoạt động của cơ chế chuyển đổi liên kết URI trong codebase này là:
  • lưu URI gốc trong dữ liệu liên kết,
  • cho phép cấu hình một script chuyển đổi ở tầng quản trị,
  • thực thi script trên từng link khi cần sinh URI public,
  • dùng kết quả đó cho các đầu ra như sitemap.
Đây là một thiết kế gọn và linh hoạt cho bài toán SEO/export URL. Điểm mạnh của nó là khả năng thay đổi quy tắc URI mà không phải sửa code lõi. Điểm cần phân biệt rõ là nó đang giải quyết bài toán “sinh URI public”, chứ chưa phải bài toán “định tuyến request theo URI đã chuyển đổi”.