14 cách Level Up API CRUD từ Ngây Thơ đến Production-Ready

Chán hoặc không yên tâm với API CRUD cơ bản? Chia sẻ với anh em 14 cách Level Up API CRUD lên, thêm ý tưởng áp dụng cho sản phẩm hoặc project để đi thực tập cũng ngon nhé.

CRUD (Create, Read, Update, Delete) chính là xương sống của mọi ứng dụng. Chúng ta, những dev, sẽ phải code nó đi code nó lại cả trăm, cả ngàn lần trong sự nghiệp. Gần như 99% logic nghiệp vụ đều quy về CRUD hết.

Vậy với các bạn mới (mới đi làm, mới học, hoặc mới rẽ từ FE sang BE), có bao giờ anh em tự hỏi: Tại sao CRUD của mình nhiều lúc cảm giác nó hơi mong manh, hơi sơ sài, hơi thiếu thiếu không?

Có bao giờ anh em thắc mắc là ở những dự án lớn, những sản phẩm thực tế và chuyên nghiệp, người ta sẽ viết thêm, làm thêm những cái gì để cái CRUD cơ bản đấy trở nên xịn hơn, bảo mật hơn và thực chiến hơn không?

Trong bài viết này, mình sẽ chia sẻ một số concept, pattern, và giải pháp để anh em có thể level up cái request của mình lên, từ Level 0: Ngây Thơ đến có thể đi làm được.

Ok, bắt đầu luôn!

I. Request dạng Đọc (GET)#

Đây là những Request không làm thay đổi dữ liệu (ví dụ: GET /products).

Level 0: Ngây Thơ (Raw Query)#

Query database (DB) thế nào, trả về y nguyên thế đó. SELECT * FROM product xong return cho FE.

Vấn đề là nó trả ra cả những field nhạy cảm (password, token) hoặc thừa thãi, rất nguy hiểm về bảo mật.

Level 1: Dọn dẹp dữ liệu (Sạch sẽ)#

Có 2 giải pháp phổ biến:

• Giải pháp 1: Chỉ SELECT những field cần thiết thay vì SELECT *.
• Giải pháp 2 (Convert DTO): Thêm một bước convert từ dữ liệu DB sang Response DTO để chỉ trả những dữ liệu cần thiết cho FE.

-- Thay vì:
SELECT * FROM users;

-- Hãy:
SELECT id, name, email, avatar FROM users;

Level 2: Phân trang (Pagination)#

Vấn đề: Nếu một Request đọc trả về 1 tỷ bản ghi mà không phân trang, nó sẽ "đạp chết" server và "đạp chết" client.

Giải pháp: LUÔN LUÔN PHÂN TRANG cho các API có thể trả về số lượng lớn bản ghi.

Các kiểu thường dùng:

Level 3: Tăng trải nghiệm người dùng (UX)#

Vấn đề: User phải next trang liên tục để tìm sản phẩm màu đỏ.

Giải pháp: Thêm các chức năng cơ bản nhưng cực kỳ quan trọng: Lọc (Filter), Tìm kiếm (Search), Sắp xếp (Sort).

GET /products?filter[color]=gold&sort[price]=asc&search=iphone

Level 4: Tăng tốc với Cache (Caching)#

Vấn đề: Có những API cực ít thay đổi (ví dụ: Review sản phẩm). Nhưng mỗi khi user vào, hệ thống lại query DB một lần.

Giải pháp: Cache dữ liệu và Invalidate Cache khi dữ liệu thay đổi.

Flow có Cache:

1. Request đến -> Kiểm tra Cache
2. Cache Hit -> Trả về ngay (cực nhanh)
3. Cache Miss -> Query DB -> Lưu vào Cache -> Trả về
4. Khi Write/Update -> Lưu DB -> Invalidate Cache Key liên quan

// Ví dụ với Redis
async function getProducts(filters) {
  const cacheKey = `products:${JSON.stringify(filters)}`;
  
  // Kiểm tra cache
  const cached = await redis.get(cacheKey);
  if (cached) return JSON.parse(cached);
  
  // Cache miss -> query DB
  const products = await db.products.findMany(filters);
  
  // Lưu cache (TTL 5 phút)
  await redis.setex(cacheKey, 300, JSON.stringify(products));
  
  return products;
}

II. Request dạng Ghi (POST, PUT, PATCH, DELETE)#

Đây là những Request làm thay đổi dữ liệu.

Level 0: Ngây Thơ (Tin tưởng FE tuyệt đối)#

FE đưa gì -> Quăng vào DB. Không kiểm tra, không validate. Nguy hiểm cực kỳ.

Level 1: Validation (Lọc dữ liệu bẩn)#

Phải validate ở đủ 3 nơi và không nơi nào được tin tưởng nơi nào:

// Ví dụ validation với Zod (Node.js)
const createProductSchema = z.object({
  name: z.string().min(1).max(255),
  price: z.number().positive(),
  quantity: z.number().int().min(0),
  email: z.string().email(),
});

// Validate trước khi xử lý
const validated = createProductSchema.parse(req.body);

Level 2: Xóa mềm (Soft Delete)#

Vấn đề: Dùng DELETE bay màu dữ liệu khỏi DB -> Không có cách nào khôi phục.

Giải pháp: Sử dụng Soft Delete. Thay vì xóa vật lý, thêm một field deleted_at. Khi xóa, chỉ Update field này. Khi query, nhớ loại bỏ các bản ghi đã bị xóa mềm.

-- Thay vì:
DELETE FROM products WHERE id = 1;

-- Soft Delete:
UPDATE products SET deleted_at = NOW() WHERE id = 1;

-- Khi query, luôn thêm điều kiện:
SELECT * FROM products WHERE deleted_at IS NULL;

Level 3: Giao tác (Transaction)#

Vấn đề: Xảy ra trong các logic phức tạp, có tính kế thừa. Ví dụ: Mua hàng = Tạo Order -> Trừ Số Lượng Product -> Tạo Payment. Nếu bước giữa lỗi, các bước trước đó đã được tạo (lỗi nghiệp vụ).

Giải pháp: Sử dụng Transaction. Đảm bảo tất cả mọi logic DB bọc trong Transaction CÙNG THÀNH CÔNG HOẶC THẤT BẠI. Nếu lỗi, các bước trước đó sẽ được Rollback, như chưa từng tồn tại.

// Ví dụ Transaction với Prisma
await prisma.$transaction(async (tx) => {
  // Bước 1: Tạo Order
  const order = await tx.order.create({ data: orderData });
  
  // Bước 2: Trừ số lượng (nếu lỗi ở đây, bước 1 cũng rollback)
  await tx.product.update({
    where: { id: productId },
    data: { quantity: { decrement: orderQuantity } },
  });
  
  // Bước 3: Tạo Payment
  await tx.payment.create({ data: { orderId: order.id, ...paymentData } });
});
// Nếu bất kỳ bước nào lỗi -> TẤT CẢ đều rollback

Level 4: Thao tác hàng loạt (Bulk Operations)#

Vấn đề: User muốn xóa 1000 sản phẩm cùng lúc. Nếu gọi 1000 lần DELETE /products/{'{id}'}, sẽ rất chậm, tốn tài nguyên, và có thể gây timeout.

Giải pháp: Hỗ trợ Bulk Operations — xử lý nhiều bản ghi trong một request duy nhất.

// POST /products/bulk-delete
// Body: { ids: [1, 2, 3, ...] }

// POST /products/bulk-update
// Body: { updates: [{ id: 1, price: 100 }, { id: 2, price: 200 }] }

III. Request nói chung (Áp dụng cho tất cả)#

Những nguyên tắc áp dụng được cho TẤT CẢ mọi Request.

Level 1: Chuẩn hóa và nhất quán (Standardization)#

Ba nguyên tắc vàng:

1. Làm đúng chuẩn RESTful:

2. Trả đúng HTTP Status Code:

3. Nhất quán Response Format:

{
  "success": true,
  "data": { "id": 1, "name": "iPhone 16" },
  "message": "Product created successfully"
}

Level 2: Định danh và phân quyền (Auth)#

Hai khái niệm cần phân biệt rõ:

• Authentication (Xác thực): Cho biết bạn là ai — thường dùng JWT Token, Session, OAuth.
• Authorization (Phân quyền): Cho biết bạn có thể làm được gì — dùng Role-based (RBAC) hoặc Permission-based.

Áp dụng thực tế:

• Chỉ user đã đăng nhập (Authentication) mới được đặt hàng.
• Chỉ Admin (Authorization) mới được quản lý sản phẩm.
• User thường chỉ được sửa/xóa dữ liệu của chính mình.

Level 3: Xử lý lỗi và Logging (Error Handling)#

Vấn đề: Lỗi không được xử lý (unhandled error) sẽ trả về 500 Internal Server Error một cách tự động, dev không có log để debug.

Giải pháp:

1. Bọc try-catch và trả lỗi hợp lý cho FE:

try {
  const product = await productService.create(data);
  return res.status(201).json({ success: true, data: product });
} catch (error) {
  if (error instanceof ValidationError) {
    return res.status(400).json({ success: false, message: error.message });
  }
  // Lỗi không lường trước
  logger.error('Create product failed', { error, data });
  return res.status(500).json({ success: false, message: 'Internal Server Error' });
}

2. Logging lỗi: Khi gặp lỗi không lường trước (Lỗi 500), phải lưu log vào file hoặc dịch vụ thứ 3 (Sentry, Datadog) để team biết và xử lý.

Level 4: Giới hạn tốc độ (Rate Limit)#

Vấn đề: API nặng (Query lâu, Upload File lớn), API tốn tiền (Gọi sang dịch vụ AI theo lượt), API dễ bị spam (Comment, Review).

Giải pháp: Áp dụng Rate Limit — giới hạn số lượng Request trên một khoảng thời gian/user.

Ví dụ: API Review sản phẩm chỉ được 1 Request/phút. Khi vượt quá giới hạn -> Trả về 429 Too Many Requests.

// Ví dụ Rate Limit config
const rateLimiter = rateLimit({
  windowMs: 60 * 1000,  // 1 phút
  max: 10,               // Tối đa 10 requests
  message: { success: false, message: 'Too many requests, please try again later.' },
});

app.use('/api/', rateLimiter);

Level 5: Tạo phiên bản (Versioning)#

Vấn đề: Ứng dụng Mobile đã lên Store không thể tùy tiện thay đổi cấu trúc API trả ra. Nếu đổi response format, app cũ sẽ crash.

Giải pháp: Tạo phiên bản API mới khi có thay đổi lớn.

/api/v1/products    → Response cũ (vẫn hoạt động)
/api/v2/products    → Response mới (thêm field, đổi format)

Level 6: Kiểm tra sức khỏe và giám sát (Health Check)#

Vấn đề: Không biết API có đang sống không, Database có kết nối được không, Redis có hoạt động không. Khi có sự cố, không biết nguyên nhân ở đâu.

Giải pháp: Tạo Health Check endpoint để kiểm tra trạng thái của hệ thống.

// GET /health
app.get('/health', async (req, res) => {
  const health = {
    status: 'ok',
    timestamp: new Date().toISOString(),
    checks: {
      database: await checkDB(),    // Có kết nối được không?
      redis: await checkRedis(),     // Có hoạt động không?
      diskSpace: checkDisk(),        // Còn đủ dung lượng không?
    },
  };
  
  const isHealthy = Object.values(health.checks).every(c => c === 'ok');
  res.status(isHealthy ? 200 : 503).json(health);
});

Tổng kết#

Vậy là chúng ta đã cùng điểm qua 14 thứ có thể áp dụng để "xào nấu" lại cái CRUD cơ bản:

Thay vì code CRUD kiểu "đưa sao lưu vậy, có sao trả ra vậy", hãy áp dụng những thứ này để dự án của anh em trông chuyên nghiệp hơn và sẵn sàng cho thực tế hơn nhé.

Tạm thời thế đã. Còn thiếu gì hay, thực tiễn, dễ áp dụng thì anh em comment thêm nhé.