Mục lục

Lesson 3.2: Hierarchical Relationships

Cách thiết kế URL cho các tài nguyên có quan hệ cha-con lồng nhau (Nesting).

API Design
REST
Nesting

Thời lượng: 25 phút
Level: Beginner
Yêu cầu: Đã hiểu về Resource Naming.

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

Sau bài học này, bạn sẽ:

  • Thiết kế được URL lồng nhau (Nested Resources) đúng chuẩn.
  • Nhận diện được vấn đề của Deep Nesting (Lồng quá sâu).
  • Biết khi nào dùng Shallow Routing (Định tuyến nông).

Nội dung chính

1. Nested Resources (Tài nguyên lồng nhau)

Trong thực tế, các tài nguyên thường có quan hệ với nhau. Ví dụ: Một bài viết (Post) có nhiều bình luận (Comments).

Cấu trúc URL chuẩn: GET /posts/{post_id}/comments

Hành độngURLÝ nghĩa
ListGET /posts/1/commentsLấy tất cả comments của post 1.
RetrieveGET /posts/1/comments/5Lấy comment ID 5 thuộc post 1.
CreatePOST /posts/1/commentsTạo comment mới cho post 1.

2. Quy tắc "Tối đa 2 cấp"

Một sai lầm phổ biến là lồng quá nhiều cấp dẫn đến URL cực kỳ dài và khó quản lý.

Sai (Deep Nesting): GET /authors/1/posts/5/comments/10/votes

Hệ quả:

  • URL quá dài.
  • Coupling (phụ thuộc) quá chặt chẽ.
  • Client phải biết quá nhiều IDs cha để lấy được dữ liệu con.

Giải pháp: Hầu hết các tài nguyên nên có thể được truy cập trực tiếp bằng ID duy nhất của nó sau 1-2 cấp.

3. Shallow Routing (Định tuyến nông)

Shallow routing giúp cân bằng giữa ngữ cảnh và sự tiện lợi.

Quy tắc:

  • Dùng Nesting cho các tập hợp (Collections) cần ngữ cảnh cha.
  • Dùng Root-level cho các hành động trên một phần tử cụ thể (nếu ID là unique toàn hệ thống).

Ví dụ:

  • GET /posts/1/comments (Hợp lý để lấy danh sách).
  • GET /comments/5 (Nên dùng thay vì /posts/1/comments/5 nếu ID của comment là unique).
  • PATCH /comments/5 (Gọn hơn so với việc kẹp thêm post_id vào URL).

Nguyên tắc then chốt

"Đừng bao giờ lồng quá 2 cấp tài nguyên trong URL."

Nếu bạn thấy mình đang viết URL có 3 dấu slash cho IDs (VD: /a/:id/b/:id/c/:id), hãy dừng lại và refactor. Hãy đưa tài nguyên cấp 3 ra ngoài root hoặc rút ngắn quan hệ.


Thực hành

Bài tập 1: Thiết kế URL cho hệ thống Khoá học

Bối cảnh: Một Khoá học (Course) có nhiều Chương (Chapters). Mỗi Chương có nhiều Bài học (Lessons).

Yêu cầu:

  • Thiết kế URL để lấy danh sách bài học của một chương.
  • Thiết kế URL để cập nhật tiêu đề của một bài học (áp dụng shallow routing).

Gợi ý:

Xem đáp án mẫu
  • Lấy danh sách: GET /chapters/123/lessons
  • Cập nhật bài học: PATCH /lessons/456 (Thay vì /courses/1/chapters/123/lessons/456)

Tình huống thực tế

Scenario 1: Quyền sở hữu (Ownership)

Bối cảnh: Bạn có URL GET /users/5/orders/10. Hệ thống trả về đơn hàng số 10 của user số 5. Nếu hacker gọi GET /users/7/orders/10 (trong khi đơn hàng 10 thuộc về user 5), hệ thống nên trả về gì?

Giải quyết: Mặc dù ID 10 tồn tại, nhưng vì nó không thuộc user 7, bạn nên trả về 404 Not Found (để tránh rò rỉ thông tin là đơn hàng 10 có tồn tại) hoặc 403 Forbidden. Đây là lợi ích của Nesting trong việc kiểm tra quyền sở hữu (Authorization).


Câu hỏi phỏng vấn

Senior Level

  1. Q: Tại sao Shallow Routing lại được ưu tiên trong các hệ thống lớn? A: Vì nó giúp giảm sự phụ thuộc vào cấu trúc cây dữ liệu. Nếu sau này tài nguyên con (VD: Comment) được di chuyển sang một tài nguyên cha khác (VD: Từ Post sang Page), các URL thao tác trực tiếp trên ID comment sẽ không bị ảnh hưởng. Nó cũng giúp đơn giản hóa code xử lý ở Backend (không cần parse quá nhiều tham số từ URL).

Tóm tắt

Những điều cần nhớ

  • Nesting tốt cho việc Query danh sách phụ thuộc.
  • Không lồng quá 2 cấp.
  • ID unique toàn hệ thống thì nên đưa về Root đối với các thao tác GET/PUT/PATCH/DELETE một phần tử đơn lẻ.

Bước tiếp theo

Bài tiếp theo: Lesson 3.3: Complex Actions - Cách xử lý những hành động phi-CRUD như: verify, cancel, approve, login...

Tiếp tục →

Quảng cáo
mdhorizontal