Cách dùng Vibe Coding để xây dựng REST API
Bùi Tấn Lực - 104
- 12/10/2026
Vibe Coding đang mở ra cách tiếp cận mới trong phát triển phần mềm: thay vì tự viết từng dòng mã, lập trình viên mô tả yêu cầu bằng ngôn ngữ tự nhiên, để AI hỗ trợ thiết kế, sinh mã và điều chỉnh chương trình theo phản hồi. Với REST API, phương pháp này có thể giúp rút ngắn thời gian xây dựng các chức năng như đăng nhập, quản lý người dùng, xử lý đơn hàng và cung cấp dữ liệu cho website hoặc ứng dụng di động.
Tuy nhiên, một REST API hoạt động được chưa chắc đã là một REST API tốt. Mã nguồn do AI tạo ra vẫn có thể chứa lỗi logic, thiếu kiểm tra dữ liệu, phân quyền không đầy đủ hoặc thiết kế endpoint thiếu nhất quán. Vì vậy, cách sử dụng Vibe Coding hiệu quả không phải là yêu cầu AI viết toàn bộ hệ thống trong một lần, mà là chia nhỏ bài toán, xác định hợp đồng API, kiểm tra từng phần và cải thiện dựa trên kết quả thực tế.
Bài viết này hướng dẫn cách ứng dụng Vibe Coding để xây dựng REST API theo quy trình có kiểm soát, từ xác định yêu cầu, lựa chọn công nghệ, thiết kế cấu trúc đến tạo endpoint, kiểm thử và chuẩn bị đưa hệ thống vào vận hành.
Vibe Coding có phù hợp để xây dựng REST API không?
Vibe Coding là phương pháp phát triển phần mềm trong đó người dùng mô tả mục tiêu, yêu cầu AI tạo hoặc chỉnh sửa mã nguồn, sau đó chạy thử và tiếp tục yêu cầu điều chỉnh. Người phát triển đóng vai trò định hướng, đánh giá kết quả và chịu trách nhiệm về chất lượng cuối cùng của hệ thống.
REST API là giao diện cho phép các ứng dụng giao tiếp với nhau thông qua HTTP. Chẳng hạn, một website bán hàng có thể gọi API để lấy danh sách sản phẩm, tạo đơn hàng hoặc xem thông tin tài khoản. API tiếp nhận yêu cầu, xử lý nghiệp vụ và trả về dữ liệu theo định dạng đã thống nhất, thường là JSON.
Hai công nghệ này có thể kết hợp tốt vì phần lớn công việc xây dựng API đều có những quy tắc tương đối rõ ràng. AI có thể hỗ trợ tạo cấu trúc dự án, viết các endpoint CRUD, xây dựng lớp xác thực dữ liệu, tạo tài liệu API và đề xuất các trường hợp kiểm thử.
Những công việc Vibe Coding có thể hỗ trợ tốt
- Tạo bộ khung dự án: thiết lập thư mục, cấu hình máy chủ, quản lý biến môi trường và khởi tạo ứng dụng.
- Xây dựng endpoint: tạo các API lấy danh sách, xem chi tiết, thêm mới, cập nhật và xóa dữ liệu.
- Xử lý dữ liệu: viết schema kiểm tra đầu vào, chuyển đổi dữ liệu và chuẩn hóa định dạng phản hồi.
- Tạo kiểm thử: đề xuất các trường hợp kiểm thử thành công, dữ liệu không hợp lệ và tình huống lỗi.
- Hỗ trợ tài liệu: tạo mô tả endpoint, tham số, cấu trúc JSON và ví dụ phản hồi.
- Sửa lỗi: phân tích thông báo lỗi, tìm nguyên nhân có khả năng xảy ra và đề xuất bản sửa để kiểm chứng.
Những việc không nên giao hoàn toàn cho AI
AI có thể tạo ra mã nguồn trông hợp lý nhưng không đáp ứng đầy đủ yêu cầu nghiệp vụ. Ví dụ, endpoint cập nhật đơn hàng có thể chạy bình thường nhưng lại cho phép khách hàng sửa đơn của người khác nếu thiếu kiểm tra quyền sở hữu.
Những quyết định liên quan đến mô hình dữ liệu, quyền truy cập, quy tắc thanh toán, tính nhất quán giao dịch và chính sách bảo mật cần được xác định rõ. AI có thể đề xuất phương án, nhưng người phát triển phải xem xét và kiểm chứng phương án đó.
Vibe Coding phù hợp nhất khi được sử dụng như một phương pháp tăng tốc phát triển có kiểm soát, thay vì một cách tạo phần mềm mà không cần hiểu mã nguồn.
Xác định yêu cầu trước khi yêu cầu AI viết mã
Đây là bước quan trọng nhất trong toàn bộ quy trình. Nếu yêu cầu ban đầu mơ hồ, AI có thể tạo ra API chạy được nhưng thiếu chức năng, sai cấu trúc dữ liệu hoặc không phù hợp với ứng dụng cần tích hợp.
Trước khi mở công cụ AI, hãy xác định API phục vụ ai, giải quyết nghiệp vụ gì, cần quản lý những dữ liệu nào và có những quy tắc truy cập ra sao.
Chọn một bài toán cụ thể để bắt đầu
Thay vì yêu cầu AI xây dựng một hệ thống thương mại điện tử hoàn chỉnh ngay từ đầu, hãy bắt đầu với một phạm vi nhỏ. Ví dụ, xây dựng REST API quản lý sản phẩm với các chức năng:
- Lấy danh sách sản phẩm.
- Xem thông tin một sản phẩm theo ID.
- Tạo sản phẩm mới.
- Cập nhật thông tin sản phẩm.
- Xóa sản phẩm.
- Tìm kiếm và phân trang danh sách.
Phạm vi này đủ để kiểm tra quy trình xử lý HTTP, xác thực dữ liệu, thao tác cơ sở dữ liệu và chuẩn hóa phản hồi. Sau khi các chức năng cơ bản hoạt động ổn định, bạn có thể bổ sung đăng nhập, phân quyền, quản lý tồn kho hoặc những nghiệp vụ phức tạp hơn.
Xác định cấu trúc dữ liệu và quy tắc nghiệp vụ
Với API quản lý sản phẩm, có thể bắt đầu bằng mô hình dữ liệu gồm các trường sau:
| Trường | Kiểu dữ liệu | Quy tắc |
|---|---|---|
| id | Số nguyên hoặc UUID | Định danh duy nhất, do hệ thống quản lý. |
| name | Chuỗi | Bắt buộc, không được chỉ chứa khoảng trắng. |
| description | Chuỗi hoặc giá trị rỗng | Mô tả sản phẩm, có thể không bắt buộc. |
| price | Số thập phân | Không âm; cần quy định độ chính xác khi lưu tiền. |
| stock | Số nguyên | Không âm, biểu thị số lượng tồn kho. |
| created_at | Ngày giờ | Thời điểm tạo bản ghi. |
Đây chỉ là mô hình minh họa. Khi triển khai thực tế, bạn cần xác định thêm các yêu cầu như sản phẩm có thể bị xóa hay chỉ chuyển sang trạng thái ngừng kinh doanh, giá có được cập nhật về 0 hay không và người dùng nào được phép thay đổi tồn kho.
Những quy tắc này nên được ghi thành yêu cầu rõ ràng trước khi AI tạo mã. Chúng giúp hạn chế việc AI tự suy diễn nghiệp vụ hoặc đưa ra những hành vi không mong muốn.
Viết tiêu chí nghiệm thu cho từng chức năng
Mỗi endpoint nên có tiêu chí để xác định khi nào chức năng được xem là hoàn thành. Ví dụ, chức năng tạo sản phẩm chỉ được chấp nhận khi đáp ứng các điều kiện:
- Dữ liệu hợp lệ thì tạo được sản phẩm và trả về thông tin bản ghi.
- Thiếu tên sản phẩm thì trả về lỗi xác thực phù hợp.
- Giá âm hoặc tồn kho âm thì bị từ chối.
- Dữ liệu gửi lên không làm lộ các trường nội bộ không được phép thay đổi.
- Lỗi cơ sở dữ liệu không khiến API trả về thông tin nhạy cảm.
Có tiêu chí nghiệm thu sẽ giúp bạn đánh giá kết quả bằng hành vi thực tế thay vì chỉ nhìn mã nguồn và cảm thấy rằng AI đã làm đúng.
Lựa chọn công nghệ và công cụ AI phù hợp
Vibe Coding không gắn với một ngôn ngữ lập trình hay một công cụ AI duy nhất. Bạn có thể sử dụng AI ngay trong trình soạn thảo mã nguồn, môi trường phát triển có khả năng chỉnh sửa nhiều tệp hoặc giao diện trò chuyện để tạo từng phần mã.
Việc lựa chọn nên dựa trên mức độ quen thuộc với công nghệ, yêu cầu triển khai, hệ sinh thái thư viện và khả năng kiểm soát những thay đổi mà AI thực hiện.
Chọn ngôn ngữ và framework theo mục tiêu dự án
| Công nghệ | Điểm mạnh | Phù hợp khi |
|---|---|---|
| Node.js với Express | Cấu trúc tương đối gọn, hệ sinh thái JavaScript phong phú. | Xây dựng API cho website hoặc ứng dụng dùng JavaScript. |
| Python với FastAPI | Khai báo kiểu dữ liệu rõ ràng, hỗ trợ tạo tài liệu OpenAPI tự động. | Muốn phát triển API nhanh và có hợp đồng dữ liệu dễ kiểm tra. |
| PHP với Laravel | Có sẵn nhiều thành phần phục vụ định tuyến, xác thực, kiểm tra dữ liệu và truy cập cơ sở dữ liệu. | Xây dựng API tích hợp với website hoặc hệ thống PHP. |
| Java với Spring Boot | Hệ sinh thái phong phú, phù hợp với ứng dụng có cấu trúc rõ ràng. | Xây dựng hệ thống doanh nghiệp hoặc dịch vụ cần tổ chức chặt chẽ. |
Không có framework nào luôn tốt nhất cho mọi dự án. Nếu bạn đã có một hệ thống PHP đang vận hành, tiếp tục sử dụng Laravel hoặc kiến trúc PHP hiện tại có thể hợp lý hơn việc chuyển sang công nghệ mới chỉ vì AI hỗ trợ tốt.
Với người mới muốn xây dựng REST API đầu tiên, FastAPI là một lựa chọn đáng cân nhắc nhờ cách khai báo dữ liệu tương đối trực quan và khả năng tạo tài liệu API. Trong hướng dẫn này, các ví dụ tiếp theo sử dụng Python và FastAPI để minh họa quy trình.
Chuẩn bị môi trường phát triển
Trước khi yêu cầu AI viết mã, hãy chuẩn bị Python phù hợp với phiên bản mà framework và các thư viện của dự án hỗ trợ, một trình soạn thảo mã nguồn, Git để quản lý phiên bản và môi trường ảo để cô lập các gói phụ thuộc.
Có thể tạo môi trường ảo bằng lệnh sau:
python -m venv .venv
Kích hoạt môi trường trên Windows:
.venvScriptsactivate
Trên Linux hoặc macOS:
source .venv/bin/activate
Sau đó, cài đặt các gói cần thiết cho ví dụ FastAPI:
python -m pip install fastapi "uvicorn[standard]"
Trong dự án thực tế, nên ghi nhận phiên bản thư viện đã kiểm thử trong tệp quản lý phụ thuộc và duy trì cách cài đặt nhất quán giữa môi trường phát triển, kiểm thử và triển khai.
Thiết kế endpoint theo nguyên tắc REST
Trước khi tạo mã nguồn, hãy thống nhất đường dẫn, phương thức HTTP, dữ liệu đầu vào và cấu trúc phản hồi. Đây là hợp đồng mà frontend, ứng dụng di động hoặc dịch vụ khác sẽ sử dụng để giao tiếp với API.
Một API có thể chạy tốt về mặt kỹ thuật nhưng vẫn khó sử dụng nếu mỗi endpoint tuân theo một quy tắc khác nhau. Thiết kế nhất quán từ đầu giúp giảm số lần sửa đổi khi hệ thống mở rộng.
Sử dụng tài nguyên làm trung tâm
REST thường biểu diễn dữ liệu dưới dạng tài nguyên, chẳng hạn như products, users hoặc orders. Đường dẫn nên thể hiện tài nguyên cần thao tác, còn phương thức HTTP thể hiện hành động.
| Phương thức | Endpoint | Mục đích |
|---|---|---|
| GET | /api/v1/products | Lấy danh sách sản phẩm. |
| GET | /api/v1/products/123 | Lấy thông tin sản phẩm có ID là 123. |
| POST | /api/v1/products | Tạo sản phẩm mới. |
| PUT | /api/v1/products/123 | Thay thế toàn bộ trạng thái có thể cập nhật của sản phẩm theo quy ước API. |
| PATCH | /api/v1/products/123 | Cập nhật một phần thông tin sản phẩm. |
| DELETE | /api/v1/products/123 | Xóa sản phẩm theo chính sách đã xác định. |
Không nên đặt đường dẫn theo kiểu /getAllProducts, /createProduct hoặc /deleteProduct/123 nếu mục tiêu là thiết kế API theo phong cách tài nguyên REST. Những đường dẫn này gắn hành động vào URL trong khi HTTP đã có phương thức biểu đạt mục đích tương ứng.
Thống nhất cấu trúc phản hồi và mã trạng thái HTTP
AI cần biết API sẽ trả về dữ liệu như thế nào trong từng tình huống. Với các yêu cầu thành công, bạn có thể trả trực tiếp đối tượng JSON hoặc sử dụng một cấu trúc bao ngoài thống nhất. Điều quan trọng là phải nhất quán trong toàn bộ hệ thống.
Ví dụ, phản hồi khi lấy một sản phẩm có thể có dạng:
{
"id": 123,
"name": "Bàn phím cơ",
"price": 850000,
"stock": 25
}
Đối với lỗi xác thực dữ liệu, API có thể trả về:
{
"error": {
"code": "VALIDATION_ERROR",
"message": "Dữ liệu đầu vào không hợp lệ",
"details": [
{
"field": "price",
"message": "Giá sản phẩm phải lớn hơn hoặc bằng 0"
}
]
}
}
Đây là cấu trúc minh họa do dự án tự quy định, không phải định dạng bắt buộc của REST. Bạn có thể chọn cấu trúc khác, miễn là tài liệu và mã nguồn thống nhất.
Một số mã trạng thái thường dùng gồm:
- 200 OK: yêu cầu thành công, chẳng hạn khi lấy dữ liệu hoặc cập nhật thành công và có nội dung phản hồi.
- 201 Created: tạo tài nguyên thành công.
- 204 No Content: yêu cầu thành công nhưng không trả nội dung, thường phù hợp với một số thao tác xóa.
- 400 Bad Request: yêu cầu không hợp lệ theo quy tắc xử lý của API.
- 401 Unauthorized: thiếu thông tin xác thực hợp lệ hoặc thông tin xác thực không hợp lệ.
- 403 Forbidden: người gọi đã được xác thực nhưng không có quyền thực hiện hành động.
- 404 Not Found: không tìm thấy tài nguyên hoặc endpoint tương ứng.
- 409 Conflict: yêu cầu xung đột với trạng thái hiện tại, chẳng hạn vi phạm một quy tắc duy nhất.
- 422 Unprocessable Content: nội dung có thể phân tích được nhưng không đáp ứng các điều kiện xử lý; cách dùng cụ thể phụ thuộc framework và hợp đồng API.
- 500 Internal Server Error: lỗi máy chủ ngoài dự kiến.
Không nên trả mã 200 cho mọi trường hợp, kể cả khi dữ liệu sai hoặc tài nguyên không tồn tại. Mã trạng thái chính xác giúp frontend xử lý lỗi rõ ràng và giúp các công cụ giám sát phát hiện vấn đề hiệu quả hơn.
Viết prompt để AI tạo REST API đúng yêu cầu
Chất lượng mã nguồn được tạo ra phụ thuộc đáng kể vào chất lượng yêu cầu. Một câu lệnh ngắn như “hãy tạo API quản lý sản phẩm” để lại quá nhiều khoảng trống cho AI tự quyết định về cấu trúc dự án, mô hình dữ liệu, mã trạng thái, kiểm tra đầu vào và cách xử lý lỗi.
Thay vì chỉ mô tả chức năng, hãy cung cấp bối cảnh kỹ thuật, phạm vi thực hiện, các quy tắc không được vi phạm và tiêu chí nghiệm thu.
Cấu trúc của một prompt hiệu quả
Một prompt dùng để xây dựng REST API nên có những thành phần sau:
- Vai trò: yêu cầu AI làm việc như một kỹ sư backend có kinh nghiệm với framework đang sử dụng.
- Bối cảnh: mô tả mục tiêu dự án, công nghệ, phiên bản và môi trường chạy.
- Phạm vi: liệt kê các endpoint và nghiệp vụ cần triển khai trong lần thực hiện hiện tại.
- Hợp đồng API: xác định phương thức HTTP, đường dẫn, trường dữ liệu, mã trạng thái và định dạng phản hồi.
- Ràng buộc: yêu cầu kiểm tra dữ liệu, xử lý lỗi, bảo mật, quản lý cấu hình và không sửa những phần không liên quan.
- Tiêu chí nghiệm thu: mô tả các tình huống phải kiểm thử và kết quả mong đợi.
- Đầu ra: yêu cầu AI liệt kê tệp đã tạo hoặc sửa, các lệnh chạy, cách kiểm thử và những điểm chưa được xử lý.
Prompt mẫu xây dựng API quản lý sản phẩm
Bạn có thể sử dụng prompt dưới đây làm điểm khởi đầu và điều chỉnh theo dự án thực tế:
Bạn là kỹ sư backend có kinh nghiệm với Python và FastAPI.
Mục tiêu:
Xây dựng REST API quản lý sản phẩm cho một ứng dụng bán hàng.
Phạm vi hiện tại:
- GET /api/v1/products: lấy danh sách sản phẩm.
- GET /api/v1/products/{product_id}: lấy chi tiết sản phẩm.
- POST /api/v1/products: tạo sản phẩm.
- PATCH /api/v1/products/{product_id}: cập nhật một phần thông tin.
- DELETE /api/v1/products/{product_id}: xóa sản phẩm.
Mô hình dữ liệu:
- id: định danh duy nhất do hệ thống tạo.
- name: bắt buộc, không được để trống.
- description: không bắt buộc.
- price: số không âm.
- stock: số nguyên không âm.
Yêu cầu kỹ thuật:
- Sử dụng FastAPI và Pydantic.
- Tách phần định tuyến, xử lý nghiệp vụ và truy cập dữ liệu ở mức phù hợp.
- Không cho phép dữ liệu đầu vào tự ghi đè các trường nội bộ.
- Chuẩn hóa mã trạng thái và phản hồi lỗi.
- Có phân trang cho danh sách sản phẩm.
- Không ghi thông tin nhạy cảm vào log.
- Không đưa mật khẩu, khóa bí mật hoặc thông tin kết nối thật vào mã nguồn.
- Viết kiểm thử cho dữ liệu hợp lệ, dữ liệu sai và tài nguyên không tồn tại.
Cách thực hiện:
1. Trước tiên, đề xuất cấu trúc thư mục và giải thích ngắn gọn.
2. Nêu các giả định nghiệp vụ cần được xác nhận.
3. Chỉ triển khai phần quản lý sản phẩm trong phạm vi trên.
4. Không tự ý bổ sung tính năng ngoài yêu cầu.
5. Sau khi viết mã, liệt kê các tệp đã tạo hoặc sửa.
6. Hướng dẫn cài đặt, khởi chạy và chạy kiểm thử.
7. Nêu rõ những giới hạn còn tồn tại, không khẳng định
chức năng đã kiểm thử nếu chưa thực sự chạy kiểm thử.
Prompt này có tác dụng giới hạn phạm vi và giúp AI hiểu thế nào là hoàn thành. Tuy nhiên, nó chưa thay thế việc kiểm tra mã nguồn, lựa chọn cơ sở dữ liệu, thiết lập cơ chế xác thực hoặc đánh giá các yêu cầu vận hành trước khi đưa API lên môi trường thực tế.
Chia nhỏ công việc thay vì yêu cầu AI tạo toàn bộ dự án một lần
Sau khi thống nhất thiết kế, hãy triển khai theo từng bước. Trình tự phù hợp là tạo khung ứng dụng, xây dựng mô hình dữ liệu, triển khai endpoint đọc dữ liệu, bổ sung thao tác ghi, viết kiểm thử rồi mới mở rộng sang xác thực và phân quyền.
Mỗi lần chỉ nên yêu cầu AI xử lý một nhóm chức năng có phạm vi rõ ràng. Nếu AI sửa quá nhiều tệp trong cùng một lượt, bạn sẽ khó xác định thay đổi nào gây ra lỗi và việc khôi phục cũng phức tạp hơn.
Trước mỗi thay đổi lớn, hãy lưu trạng thái mã nguồn bằng Git. Sau khi AI hoàn thành, xem phần chênh lệch giữa phiên bản cũ và mới, kiểm tra các tệp bị sửa và chạy những bài kiểm thử liên quan.
Nguyên tắc quan trọng là không chuyển sang bước tiếp theo chỉ vì AI thông báo đã hoàn thành. Chỉ tiếp tục khi kết quả hiện tại đáp ứng các tiêu chí đã đặt ra.
Xây dựng REST API đầu tiên bằng FastAPI và Vibe Coding
Sau khi đã xác định yêu cầu và thiết kế endpoint, bạn có thể bắt đầu tạo ứng dụng. Để dễ hiểu cách phối hợp với AI, ví dụ dưới đây sử dụng một API quản lý sản phẩm đơn giản, lưu dữ liệu trong bộ nhớ của tiến trình Python.
Cách lưu này chỉ phục vụ minh họa luồng xử lý HTTP. Dữ liệu sẽ mất khi khởi động lại ứng dụng và không phù hợp với môi trường nhiều tiến trình hoặc hệ thống thực tế. Khi triển khai thật, cần thay bằng cơ sở dữ liệu phù hợp.
Tạo ứng dụng và khai báo mô hình dữ liệu
Tạo tệp main.py và yêu cầu AI xây dựng mô hình dữ liệu bằng Pydantic. Mô hình cần phân biệt dữ liệu mà người dùng được phép gửi lên với dữ liệu do hệ thống quản lý.
Ví dụ, người dùng có thể cung cấp tên sản phẩm, giá và tồn kho, nhưng không được tự chọn ID hoặc ghi đè thời điểm tạo bản ghi. Việc tách mô hình đầu vào và mô hình phản hồi giúp hạn chế các trường hợp ghi đè dữ liệu ngoài ý muốn.
from fastapi import FastAPI, HTTPException, Query, Response
from pydantic import BaseModel, Field
app = FastAPI(
title="Product API",
version="1.0.0"
)
class ProductCreate(BaseModel):
name: str = Field(min_length=1, max_length=200)
description: str | None = None
price: float = Field(ge=0)
stock: int = Field(ge=0)
class ProductUpdate(BaseModel):
name: str | None = Field(
default=None,
min_length=1,
max_length=200
)
description: str | None = None
price: float | None = Field(default=None, ge=0)
stock: int | None = Field(default=None, ge=0)
class Product(ProductCreate):
id: int
products: dict[int, Product] = {}
next_product_id = 1
Trong ví dụ này, ProductCreate mô tả dữ liệu tạo mới, ProductUpdate mô tả các trường có thể cập nhật và Product bổ sung ID do hệ thống quản lý.
Với môi trường sử dụng Python 3.10 trở lên, các kiểu như str | None có thể được dùng để biểu diễn trường có thể nhận giá trị rỗng. Nếu dự án sử dụng phiên bản Python cũ hơn, cần điều chỉnh cú pháp cho tương thích.
Cần lưu ý thêm rằng price đang dùng kiểu số thực để giữ ví dụ ngắn gọn. Với hệ thống tài chính hoặc bán hàng thực tế, nên cân nhắc kiểu Decimal và kiểu cột dữ liệu phù hợp để tránh sai số khi xử lý tiền.
Tạo endpoint lấy danh sách và xem chi tiết
Hai endpoint đọc dữ liệu là bước đầu phù hợp để kiểm tra định tuyến, kiểu phản hồi và hành vi khi tài nguyên không tồn tại. Khi danh sách có nhiều bản ghi, nên hỗ trợ phân trang thay vì trả về toàn bộ dữ liệu trong một lần.
@app.get("/api/v1/products")
def list_products(
limit: int = Query(default=20, ge=1, le=100),
offset: int = Query(default=0, ge=0)
):
items = list(products.values())
return {
"items": items[offset:offset + limit],
"limit": limit,
"offset": offset,
"total": len(items)
}
@app.get("/api/v1/products/{product_id}")
def get_product(product_id: int):
product = products.get(product_id)
if product is None:
raise HTTPException(
status_code=404,
detail="Không tìm thấy sản phẩm"
)
return product
Endpoint danh sách sử dụng hai tham số limit và offset. Ví dụ, yêu cầu /api/v1/products?limit=10&offset=20 sẽ lấy tối đa 10 sản phẩm tiếp theo sau 20 vị trí đầu tiên trong danh sách.
Tham số giới hạn giúp tránh việc người dùng yêu cầu một lượng dữ liệu quá lớn trong một lần gọi. Trong hệ thống có nhiều dữ liệu, cần bổ sung sắp xếp ổn định và sử dụng truy vấn phân trang ở tầng cơ sở dữ liệu thay vì tải toàn bộ bản ghi vào bộ nhớ.
Triển khai endpoint tạo, cập nhật và xóa sản phẩm
Sau khi các endpoint đọc dữ liệu hoạt động, hãy yêu cầu AI triển khai các thao tác ghi. Đây là nhóm chức năng cần chú ý hơn vì chúng thay đổi trạng thái hệ thống.
@app.post("/api/v1/products", status_code=201)
def create_product(payload: ProductCreate):
global next_product_id
product = Product(
id=next_product_id,
**payload.model_dump()
)
products[next_product_id] = product
next_product_id += 1
return product
@app.patch("/api/v1/products/{product_id}")
def update_product(
product_id: int,
payload: ProductUpdate
):
product = products.get(product_id)
if product is None:
raise HTTPException(
status_code=404,
detail="Không tìm thấy sản phẩm"
)
changes = payload.model_dump(exclude_unset=True)
updated_data = product.model_dump()
updated_data.update(changes)
updated_product = Product(**updated_data)
products[product_id] = updated_product
return updated_product
@app.delete("/api/v1/products/{product_id}", status_code=204)
def delete_product(product_id: int):
if product_id not in products:
raise HTTPException(
status_code=404,
detail="Không tìm thấy sản phẩm"
)
del products[product_id]
return Response(status_code=204)
Endpoint tạo sản phẩm trả về mã trạng thái 201 khi tạo thành công. Endpoint cập nhật sử dụng exclude_unset=True để chỉ áp dụng những trường thực sự được gửi trong yêu cầu, còn endpoint xóa trả về 204 và không có nội dung phản hồi.
Đoạn mã trên là ví dụ học tập, chưa phải phiên bản sẵn sàng cho môi trường sản xuất. Chẳng hạn, trường description có thể được gửi với giá trị null, nhưng cách diễn giải giá trị này cần được xác định rõ trong hợp đồng API. Bạn cũng cần cân nhắc kiểu dữ liệu tiền tệ, tính nhất quán khi cập nhật đồng thời, lưu trữ lâu dài và chính sách xóa dữ liệu.
Trong quá trình Vibe Coding, hãy yêu cầu AI giải thích từng quyết định quan trọng và đối chiếu với yêu cầu ban đầu. Nếu mã nguồn có hành vi không mong muốn, cung cấp tình huống tái hiện cụ thể thay vì yêu cầu chung chung như “sửa cho đúng”.
Khởi chạy và kiểm tra API
Lưu mã nguồn vào tệp main.py, sau đó chạy máy chủ phát triển bằng lệnh:
uvicorn main:app --reload
Sau khi máy chủ khởi động thành công, FastAPI mặc định cung cấp tài liệu tương tác tại đường dẫn /docs và tài liệu OpenAPI tại /openapi.json. Bạn có thể dùng giao diện này để gửi thử yêu cầu đến các endpoint.
Hãy thử theo thứ tự: tạo sản phẩm, lấy danh sách, xem chi tiết theo ID, cập nhật giá hoặc tồn kho, rồi xóa sản phẩm. Tiếp tục kiểm tra các trường hợp nhập giá âm, tồn kho âm, tên rỗng và ID không tồn tại.
Đừng chỉ kiểm tra trường hợp thành công. Một API đáng tin cậy cần từ chối dữ liệu không hợp lệ bằng phản hồi rõ ràng, không làm ứng dụng bị dừng và không để trạng thái dữ liệu rơi vào tình huống không nhất quán.
Đến đây, bạn đã có quy trình cơ bản để dùng Vibe Coding tạo một REST API: xác định yêu cầu, thiết kế hợp đồng, yêu cầu AI sinh mã theo từng phần và chạy thử các endpoint. Tuy nhiên, trước khi áp dụng cho dự án thật, cần tiếp tục kiểm thử tự động, kết nối cơ sở dữ liệu, kiểm soát truy cập và xử lý các tình huống vận hành.
Kiểm thử REST API do AI tạo ra trước khi sử dụng
Một trong những sai lầm phổ biến khi sử dụng Vibe Coding là chỉ chạy thử API trên trình duyệt, thấy dữ liệu trả về đúng rồi cho rằng chức năng đã hoàn thành. Trên thực tế, một endpoint có thể hoạt động với dữ liệu mẫu nhưng vẫn gặp lỗi khi nhận dữ liệu không hợp lệ, xử lý nhiều yêu cầu liên tiếp hoặc truy cập vào tài nguyên không tồn tại.
Vì vậy, kiểm thử phải là một phần của quy trình phát triển ngay từ đầu, không phải công việc thực hiện sau khi AI đã tạo xong toàn bộ ứng dụng. Bạn nên yêu cầu AI xây dựng các trường hợp kiểm thử dựa trên tiêu chí nghiệm thu, sau đó tự chạy và kiểm tra kết quả.
Kiểm thử các tình huống thành công và thất bại
Đối với API quản lý sản phẩm trong ví dụ trước, hãy chia kiểm thử thành các nhóm cụ thể:
- Kiểm thử chức năng: tạo sản phẩm, lấy danh sách, xem chi tiết, cập nhật và xóa dữ liệu.
- Kiểm thử dữ liệu đầu vào: gửi tên rỗng, giá âm, tồn kho âm hoặc sai kiểu dữ liệu.
- Kiểm thử tài nguyên: truy cập ID không tồn tại hoặc xóa một sản phẩm đã bị xóa.
- Kiểm thử ranh giới: gửi tên đạt độ dài tối đa, danh sách có số lượng bản ghi lớn và tham số phân trang ở giới hạn cho phép.
- Kiểm thử tính nhất quán: cập nhật một trường không được làm thay đổi những trường khác.
- Kiểm thử bảo mật: thử truy cập dữ liệu hoặc thực hiện thao tác khi thiếu quyền.
Với mỗi trường hợp, cần xác định trước mã trạng thái, cấu trúc phản hồi và trạng thái dữ liệu mong đợi. Cách làm này giúp phát hiện những lỗi mà việc kiểm tra thủ công thông thường dễ bỏ qua.
Sử dụng pytest để tự động hóa kiểm thử
Đối với ứng dụng FastAPI, bạn có thể dùng pytest kết hợp với TestClient để kiểm thử endpoint mà không cần gửi từng yêu cầu bằng tay.
Cài đặt các gói kiểm thử cần thiết:
python -m pip install pytest httpx
Tạo tệp test_products.py để kiểm tra một số hành vi cơ bản của API:
from fastapi.testclient import TestClient
from main import app, products
client = TestClient(app)
def setup_function():
products.clear()
def test_create_product():
response = client.post(
"/api/v1/products",
json={
"name": "Bàn phím cơ",
"description": "Bàn phím dùng cho máy tính",
"price": 850000,
"stock": 10
}
)
assert response.status_code == 201
data = response.json()
assert data["name"] == "Bàn phím cơ"
assert data["price"] == 850000
assert "id" in data
def test_reject_negative_price():
response = client.post(
"/api/v1/products",
json={
"name": "Chuột máy tính",
"price": -100,
"stock": 5
}
)
assert response.status_code == 422
def test_product_not_found():
response = client.get("/api/v1/products/999999")
assert response.status_code == 404
Chạy kiểm thử bằng lệnh:
pytest -q
Ví dụ trên minh họa cách kiểm tra chức năng tạo sản phẩm, từ chối giá âm và trả về lỗi khi không tìm thấy tài nguyên. Do ứng dụng mẫu lưu dữ liệu trong bộ nhớ, phần thiết lập kiểm thử xóa dữ liệu sản phẩm trước mỗi bài kiểm thử.
Trong một dự án thực tế, bạn nên sử dụng cơ sở dữ liệu dành riêng cho kiểm thử hoặc cơ chế tạo dữ liệu thử nghiệm độc lập. Nếu ứng dụng có nhiều trạng thái toàn cục, việc chỉ xóa một danh sách dữ liệu có thể chưa đủ để bảo đảm các bài kiểm thử hoàn toàn độc lập.
Lưu ý: Đoạn mã trên là ví dụ minh họa, không phải bằng chứng rằng các bài kiểm thử đã được thực thi thành công trong môi trường của bạn. Hãy chạy thực tế, đọc thông báo lỗi và yêu cầu AI xử lý những lỗi có thể tái hiện.
Yêu cầu AI tạo kiểm thử có mục tiêu
Thay vì yêu cầu AI viết càng nhiều bài kiểm thử càng tốt, hãy đưa ra một danh sách hành vi cụ thể cần xác minh.
Hãy viết kiểm thử tự động cho endpoint tạo và cập nhật sản phẩm. Bao gồm dữ liệu hợp lệ, tên rỗng, giá âm, tồn kho âm, ID không tồn tại và trường hợp cập nhật chỉ một thuộc tính. Kiểm tra cả mã trạng thái, nội dung phản hồi và việc những trường không được gửi lên vẫn giữ nguyên giá trị. Không sửa mã nguồn ứng dụng nếu chưa giải thích rõ nguyên nhân cần sửa.
Cách yêu cầu này giúp AI tập trung vào hành vi của API thay vì chỉ tạo các bài kiểm thử đơn giản để đạt số lượng. Đối với những chức năng quan trọng, bạn cũng nên xem xét kiểm thử tích hợp và kiểm thử xuyên suốt quy trình nghiệp vụ.
Kết nối cơ sở dữ liệu để lưu trữ dữ liệu lâu dài
API sử dụng dữ liệu trong bộ nhớ chỉ phù hợp để minh họa. Khi máy chủ khởi động lại, dữ liệu có thể mất; khi chạy nhiều tiến trình, mỗi tiến trình có thể giữ một bản dữ liệu riêng. Vì vậy, ứng dụng thực tế cần sử dụng hệ quản trị cơ sở dữ liệu phù hợp.
AI có thể hỗ trợ xây dựng lớp truy cập dữ liệu, tạo mô hình bảng, viết truy vấn và sinh các bước chuyển đổi cấu trúc dữ liệu. Tuy nhiên, bạn vẫn phải kiểm tra tính nhất quán của dữ liệu, cách quản lý kết nối và hành vi của các thao tác đồng thời.
Chọn cơ sở dữ liệu theo yêu cầu dự án
| Cơ sở dữ liệu | Điểm phù hợp | Điều cần cân nhắc |
|---|---|---|
| PostgreSQL | Hệ thống có quan hệ dữ liệu rõ ràng, cần giao dịch và ràng buộc toàn vẹn. | Cần thiết kế schema, chỉ mục và chiến lược sao lưu phù hợp. |
| MySQL | Website, hệ thống quản lý và nhiều ứng dụng backend phổ biến. | Cần xác định kiểu dữ liệu, chỉ mục và cấu hình giao dịch phù hợp với nghiệp vụ. |
| SQLite | Ứng dụng nhỏ, thử nghiệm hoặc công cụ cần cơ sở dữ liệu dạng tệp. | Cần đánh giá giới hạn về ghi đồng thời và mô hình triển khai. |
| MongoDB | Dữ liệu tài liệu có cấu trúc linh hoạt và phù hợp với mô hình truy cập. | Cần thiết kế cấu trúc tài liệu và chiến lược cập nhật dữ liệu cẩn thận. |
Không nên chọn cơ sở dữ liệu chỉ vì AI tạo được mã kết nối nhanh. Hãy xem xét mối quan hệ giữa dữ liệu, yêu cầu giao dịch, cách truy vấn và khả năng vận hành. Với hệ thống quản lý đơn hàng, chẳng hạn, các thao tác trừ tồn kho và ghi nhận đơn hàng có thể cần được thực hiện trong cùng một giao dịch để tránh trạng thái không nhất quán.
Tách lớp truy cập dữ liệu khỏi endpoint
Một API được tổ chức tốt không nên đặt toàn bộ truy vấn cơ sở dữ liệu, quy tắc nghiệp vụ và xử lý HTTP trong cùng một hàm. Với dự án có quy mô vừa trở lên, bạn có thể tách các thành phần theo trách nhiệm:
- Router: tiếp nhận yêu cầu HTTP, khai báo đường dẫn và xác định mã trạng thái.
- Schema: xác thực dữ liệu đầu vào và định nghĩa cấu trúc đầu ra.
- Service: xử lý quy tắc nghiệp vụ như cập nhật giá, kiểm tra tồn kho hoặc xác nhận đơn hàng.
- Repository: tập trung các thao tác truy vấn và ghi dữ liệu.
- Model: biểu diễn cấu trúc dữ liệu theo cách phù hợp với công nghệ lưu trữ.
- Configuration: quản lý cấu hình ứng dụng và thông tin kết nối.
Đây không phải là cấu trúc bắt buộc cho mọi dự án. Một API nhỏ có thể sử dụng ít lớp hơn để tránh phức tạp không cần thiết. Mục tiêu là tạo ranh giới rõ ràng, giúp việc kiểm thử, thay đổi cơ sở dữ liệu và sửa lỗi dễ kiểm soát.
Khi sử dụng Vibe Coding, bạn nên yêu cầu AI giải thích vai trò của từng thành phần trước khi tạo hàng loạt tệp. Nếu dự án đã có kiến trúc, hãy yêu cầu AI tuân thủ cấu trúc hiện tại thay vì tự ý dựng lại toàn bộ.
Quản lý thay đổi cấu trúc dữ liệu bằng migration
Khi bổ sung trường mới, thay đổi kiểu dữ liệu hoặc tạo bảng, không nên chỉnh sửa cơ sở dữ liệu thủ công mà không lưu lại lịch sử. Hãy sử dụng công cụ migration phù hợp với framework và hệ quản trị dữ liệu.
Migration giúp ghi nhận các thay đổi theo phiên bản, cho phép nhóm phát triển tái tạo cấu trúc dữ liệu và phối hợp triển khai giữa nhiều môi trường. Tuy nhiên, không phải migration nào cũng có thể hoàn tác an toàn, đặc biệt khi đã xóa cột hoặc biến đổi dữ liệu đang được sử dụng.
Hãy yêu cầu AI giải thích tác động của migration, xác định dữ liệu có nguy cơ bị mất và đề xuất phương án sao lưu trước khi thực hiện các thay đổi quan trọng. Với hệ thống đang hoạt động, cần xem xét khả năng tương thích giữa phiên bản API cũ và cấu trúc dữ liệu mới.
Bổ sung xác thực và phân quyền cho REST API
Đối với API có dữ liệu người dùng, đơn hàng hoặc thông tin nội bộ, việc xác thực và phân quyền là yêu cầu cốt lõi. Không nên đưa API lên môi trường công khai chỉ vì các endpoint đã chạy đúng với dữ liệu thử nghiệm.
Hai khái niệm này cần được phân biệt rõ. Xác thực xác định người hoặc hệ thống đang gửi yêu cầu. Phân quyền quyết định chủ thể đó được phép thực hiện hành động nào trên tài nguyên cụ thể.
Chọn cơ chế xác thực phù hợp
Tùy vào kiến trúc ứng dụng, bạn có thể sử dụng session, token truy cập hoặc OAuth 2.0 và OpenID Connect thông qua một hệ thống định danh phù hợp.
Với ứng dụng có frontend và backend riêng, token có thể là một lựa chọn phù hợp, nhưng không phải mọi dự án đều cần tự xây dựng hệ thống cấp token. Nếu đã có nền tảng định danh hoặc nhà cung cấp xác thực đáng tin cậy, tích hợp đúng giao thức thường an toàn và dễ bảo trì hơn việc tự triển khai mọi thành phần.
Nếu sử dụng token dạng bearer, cần lưu ý rằng bất kỳ ai sở hữu token hợp lệ đều có thể sử dụng nó trong phạm vi quyền được cấp. Vì vậy, cần bảo vệ token, giới hạn thời hạn sử dụng, kiểm tra chữ ký và các thuộc tính liên quan theo đúng cơ chế xác thực.
Đặc biệt, không nên yêu cầu AI tự nghĩ ra thuật toán mã hóa, tự tạo cơ chế quản lý mật khẩu hoặc xây dựng giao thức xác thực tùy biến mà không có căn cứ bảo mật rõ ràng.
Kiểm tra quyền trên từng tài nguyên
Một lỗi nghiêm trọng thường gặp là API chỉ kiểm tra người dùng đã đăng nhập mà không kiểm tra họ có quyền truy cập bản ghi đang yêu cầu hay không.
Ví dụ, một ứng dụng quản lý đơn hàng có hai người dùng A và B. Nếu A biết ID đơn hàng của B và gọi endpoint lấy chi tiết đơn hàng, hệ thống không được trả dữ liệu chỉ vì A đã đăng nhập thành công.
Quy trình kiểm tra nên bao gồm:
- Xác minh thông tin xác thực của người gửi yêu cầu.
- Xác định vai trò và các quyền liên quan.
- Kiểm tra quyền truy cập đối với tài nguyên cụ thể.
- Thực hiện nghiệp vụ chỉ khi tất cả điều kiện cần thiết được đáp ứng.
- Trả về phản hồi phù hợp mà không tiết lộ dữ liệu nhạy cảm.
Đối với dữ liệu đa người dùng, hãy ưu tiên kiểm tra quyền ở phía máy chủ và gắn điều kiện truy vấn với phạm vi dữ liệu mà người dùng được phép truy cập. Không dựa vào việc frontend ẩn nút sửa hoặc nút xóa để bảo vệ API.
Prompt mẫu để bổ sung xác thực và phân quyền
Khi cần bổ sung bảo mật cho API đã có, hãy yêu cầu AI làm việc trong phạm vi cụ thể:
Hãy rà soát API hiện tại để xác định các endpoint cần xác thực và phân quyền. Giữ nguyên hợp đồng API không liên quan. Sử dụng cơ chế xác thực phù hợp với kiến trúc dự án, không tự tạo thuật toán mật mã. Kiểm tra quyền truy cập trên từng tài nguyên, ngăn người dùng đọc hoặc sửa dữ liệu của người khác, không lưu thông tin bí mật trong mã nguồn. Viết kiểm thử cho trường hợp chưa đăng nhập, không đủ quyền và truy cập tài nguyên thuộc người dùng khác. Trước khi sửa, hãy liệt kê các rủi ro phát hiện được và kế hoạch xử lý.
Sau khi AI hoàn thành, cần kiểm tra cả luồng xác thực lẫn phân quyền. Một API có thể từ chối người chưa đăng nhập nhưng vẫn có lỗ hổng nếu người dùng đã đăng nhập được phép truy cập dữ liệu ngoài phạm vi của họ.
Bảo mật REST API khi phát triển bằng Vibe Coding
AI giúp viết mã nhanh hơn nhưng không tự động bảo đảm hệ thống an toàn. Thậm chí, khi yêu cầu không đầy đủ, AI có thể tạo ra các giải pháp chỉ đáp ứng trường hợp thông thường mà bỏ qua các rủi ro như lộ dữ liệu, lạm dụng tài nguyên hoặc thao tác trái phép.
Đối với một REST API thực tế, bảo mật cần được xem xét xuyên suốt từ thiết kế dữ liệu, xử lý đầu vào đến cấu hình máy chủ và giám sát vận hành.
Không tin tưởng dữ liệu do client gửi lên
Mọi dữ liệu từ client đều phải được xem là đầu vào chưa đáng tin cậy, kể cả khi frontend đã kiểm tra trước đó. Người dùng có thể bỏ qua giao diện và gửi HTTP request trực tiếp đến API.
Các biện pháp cần xem xét gồm:
- Kiểm tra kiểu dữ liệu, độ dài, định dạng và miền giá trị cho phép.
- Giới hạn kích thước request và số lượng phần tử trong các mảng.
- Sử dụng truy vấn có tham số hoặc cơ chế truy cập dữ liệu an toàn.
- Không ghép trực tiếp dữ liệu người dùng vào câu lệnh SQL.
- Chỉ cho phép cập nhật các trường được công khai trong hợp đồng API.
- Kiểm tra kỹ dữ liệu tải lên, bao gồm loại tệp, kích thước và quyền truy cập.
Không nên chỉ dựa vào prompt yêu cầu AI “viết code bảo mật”. Hãy yêu cầu những biện pháp cụ thể và tạo kiểm thử để xác minh chúng.
Bảo vệ khóa bí mật và thông tin cấu hình
Thông tin kết nối cơ sở dữ liệu, khóa ký token, khóa API và mật khẩu không nên được ghi trực tiếp vào mã nguồn hoặc đưa vào các ví dụ có thể bị công khai.
Trong môi trường phát triển, có thể sử dụng tệp môi trường cục bộ và bảo đảm tệp đó không bị đưa lên kho mã nguồn. Trong môi trường vận hành, nên sử dụng cơ chế quản lý bí mật phù hợp với hạ tầng triển khai.
Đồng thời, cần tránh đưa token, mật khẩu hoặc dữ liệu cá nhân vào prompt gửi cho công cụ AI khi không cần thiết. Nếu công cụ được tích hợp trực tiếp với kho mã nguồn, hãy xem xét quyền truy cập và phạm vi chỉnh sửa mà công cụ được cấp.
Giới hạn tần suất và chống lạm dụng
Một endpoint không có giới hạn phù hợp có thể bị gọi liên tục, gây tăng chi phí, làm cạn tài nguyên hoặc ảnh hưởng đến người dùng khác. Điều này đặc biệt quan trọng với các API gửi email, xử lý tệp, tìm kiếm tốn tài nguyên hoặc gọi dịch vụ AI bên ngoài.
Tùy nghiệp vụ, bạn có thể áp dụng giới hạn tốc độ, giới hạn kích thước yêu cầu, thời gian chờ tối đa và hạn mức sử dụng theo tài khoản. Những biện pháp này nên được triển khai tại tầng phù hợp, chẳng hạn ứng dụng, API gateway hoặc hạ tầng bảo vệ phía trước máy chủ.
Không nên áp dụng một giới hạn giống nhau cho tất cả endpoint. API đọc danh sách nhỏ và endpoint tạo báo cáo nặng có thể cần chính sách khác nhau.
Kiểm soát CORS và cấu hình triển khai
CORS là cơ chế trình duyệt sử dụng để kiểm soát việc một trang web có được phép đọc phản hồi từ một nguồn khác hay không. Cấu hình CORS cần phù hợp với các origin thực sự được phép sử dụng API.
Không nên mặc định cho phép mọi origin kèm thông tin xác thực. Đồng thời, cũng không nên hiểu CORS là cơ chế xác thực người dùng hoặc là lớp bảo vệ duy nhất cho API, bởi các client không chạy trong trình duyệt vẫn có thể gửi yêu cầu trực tiếp.
Trước khi triển khai, hãy kiểm tra HTTPS, cấu hình máy chủ, quyền truy cập cơ sở dữ liệu, chính sách log và cách xử lý lỗi. Những thông tin như đường dẫn nội bộ, truy vấn SQL, stack trace hoặc khóa bí mật không nên xuất hiện trong phản hồi lỗi dành cho client.
Sửa lỗi hiệu quả khi AI tạo mã nguồn REST API
Trong quá trình Vibe Coding, lỗi là điều bình thường. Vấn đề không nằm ở việc AI có tạo ra lỗi hay không, mà ở cách bạn xác định nguyên nhân và kiểm soát quá trình sửa chữa.
Nếu chỉ gửi thông báo “API bị lỗi, sửa giúp tôi”, AI có thể đưa ra nhiều thay đổi không cần thiết hoặc vô tình tạo thêm lỗi mới. Cách tốt hơn là cung cấp bằng chứng, xác định hành vi mong đợi và giới hạn phạm vi sửa.
Cung cấp đủ thông tin để tái hiện lỗi
Một yêu cầu sửa lỗi hiệu quả nên bao gồm:
- Endpoint và phương thức HTTP gặp lỗi.
- Dữ liệu đầu vào đã sử dụng, sau khi loại bỏ thông tin nhạy cảm.
- Mã trạng thái và phản hồi thực tế.
- Kết quả mong đợi theo yêu cầu nghiệp vụ.
- Thông báo lỗi hoặc phần log liên quan.
- Các bước có thể lặp lại để tái hiện vấn đề.
- Những phần mã nguồn không được thay đổi ngoài phạm vi cần thiết.
Không gửi toàn bộ log chứa mật khẩu, token hoặc dữ liệu khách hàng nếu những thông tin đó không cần thiết để phân tích lỗi.
Quy trình xử lý lỗi theo từng bước
- Tái hiện: xác nhận lỗi có thể xảy ra theo những bước cụ thể.
- Khoanh vùng: xác định lỗi nằm ở định tuyến, xác thực dữ liệu, nghiệp vụ, cơ sở dữ liệu hay cấu hình.
- Phân tích nguyên nhân: yêu cầu AI giải thích giả thuyết và bằng chứng hỗ trợ.
- Sửa tối thiểu: chỉ thay đổi phần cần thiết để khắc phục nguyên nhân.
- Chạy lại kiểm thử: xác minh lỗi đã được xử lý và các chức năng liên quan vẫn hoạt động.
- Rà soát thay đổi: xem lại mã nguồn và loại bỏ những chỉnh sửa không cần thiết.
Nếu chưa xác định được nguyên nhân, hãy yêu cầu AI đưa ra các giả thuyết có thể kiểm chứng thay vì sửa ngẫu nhiên. Điều này đặc biệt hữu ích khi lỗi xuất hiện trong môi trường triển khai nhưng không tái hiện được trên máy phát triển.
Prompt mẫu để sửa lỗi mà không phá vỡ chức năng cũ
Endpoint PATCH /api/v1/products/{product_id} trả về kết quả không đúng khi chỉ cập nhật trường stock. Kết quả mong đợi là chỉ thay đổi stock, còn name, description và price phải giữ nguyên nếu không được gửi trong request. Hãy phân tích nguyên nhân dựa trên mã nguồn hiện có, đưa ra cách tái hiện và đề xuất bản sửa tối thiểu. Không thay đổi hợp đồng API hoặc cấu trúc dữ liệu ngoài phạm vi cần thiết. Bổ sung kiểm thử tái hiện lỗi và chạy các bài kiểm thử liên quan trước khi kết luận.
Prompt này tốt hơn yêu cầu sửa lỗi chung chung vì nó xác định hành vi sai, kết quả mong đợi và phạm vi được phép thay đổi.
Đưa REST API vào môi trường thực tế
Sau khi hoàn thành chức năng và kiểm thử, bạn cần chuẩn bị cho việc vận hành. Môi trường phát triển thường có cấu hình đơn giản và dữ liệu nhỏ, trong khi môi trường thực tế phải xử lý lỗi hạ tầng, nhiều yêu cầu đồng thời, dữ liệu lâu dài và nhu cầu giám sát.
Phân biệt môi trường phát triển và sản xuất
Lệnh chạy máy chủ với chế độ tự tải lại phù hợp để phát triển nhưng không nên được xem là cấu hình triển khai sản xuất hoàn chỉnh.
Trong môi trường thực tế, cần sử dụng cấu hình máy chủ phù hợp, quản lý biến môi trường, thiết lập HTTPS thông qua hạ tầng thích hợp và xác định cách khởi động lại dịch vụ khi tiến trình gặp sự cố.
Nếu sử dụng container, hãy bảo đảm hình ảnh triển khai không chứa khóa bí mật, mã nguồn không cần thiết hoặc dữ liệu thử nghiệm. Đồng thời, cần có quy trình xây dựng, kiểm thử và phát hành phiên bản có thể lặp lại.
Thiết lập log, giám sát và sao lưu
Một API không chỉ cần trả kết quả chính xác mà còn phải giúp người vận hành hiểu chuyện gì đang xảy ra. Hãy cân nhắc ghi nhận các thông tin như thời điểm, endpoint, mã trạng thái, thời gian xử lý và mã định danh yêu cầu.
Không ghi toàn bộ nội dung request hoặc response một cách mặc định nếu chúng có thể chứa thông tin cá nhân, token hay dữ liệu nhạy cảm. Log cần phục vụ điều tra sự cố nhưng vẫn phải tuân thủ chính sách bảo vệ dữ liệu.
Đối với cơ sở dữ liệu, hãy xây dựng chiến lược sao lưu và kiểm tra khả năng khôi phục. Một bản sao lưu chưa từng được thử khôi phục không đủ để chứng minh hệ thống có thể phục hồi khi xảy ra sự cố.
Tối ưu hiệu năng dựa trên dữ liệu thực tế
AI có thể đề xuất cache, truy vấn song song, chỉ mục hoặc tối ưu cấu trúc dữ liệu, nhưng không phải đề xuất nào cũng mang lại lợi ích. Trước khi tối ưu, hãy đo thời gian phản hồi, mức sử dụng CPU, bộ nhớ và hiệu năng truy vấn.
Những vấn đề thường cần xem xét gồm:
- Truy vấn cơ sở dữ liệu lặp lại không cần thiết.
- Thiếu chỉ mục ở các trường thường xuyên được tìm kiếm hoặc sắp xếp.
- Trả về quá nhiều trường hoặc quá nhiều bản ghi trong một request.
- Không đặt thời gian chờ cho các dịch vụ bên ngoài.
- Thực hiện công việc nặng đồng bộ trong luồng xử lý yêu cầu.
- Cache dữ liệu nhưng không có chính sách làm mới hoặc vô hiệu hóa phù hợp.
Hãy yêu cầu AI giải thích tác động của từng phương án, nêu những đánh đổi và đề xuất cách đo lường kết quả. Không nên áp dụng một giải pháp phức tạp chỉ vì nó khiến mã nguồn trông chuyên nghiệp hơn.
Những sai lầm cần tránh khi dùng Vibe Coding xây dựng API
Vibe Coding có thể tăng tốc đáng kể quá trình phát triển, nhưng cũng dễ tạo cảm giác rằng một hệ thống đã hoàn thiện chỉ vì nhiều chức năng được sinh ra trong thời gian ngắn. Những sai lầm dưới đây thường khiến dự án khó bảo trì hoặc phát sinh rủi ro khi triển khai.
Yêu cầu AI xây dựng quá nhiều chức năng cùng lúc
Khi giao một yêu cầu quá lớn, AI có thể tạo nhiều tệp và chức năng phụ thuộc lẫn nhau nhưng không đồng nhất về cấu trúc dữ liệu hoặc quy tắc nghiệp vụ. Khi xảy ra lỗi, việc xác định phần gây ra vấn đề cũng khó hơn.
Cách khắc phục là chia dự án thành các phần có thể kiểm chứng độc lập. Hoàn thành và kiểm thử một nhóm chức năng trước khi chuyển sang nhóm tiếp theo.
Chỉ kiểm tra trường hợp thành công
Một API trả về dữ liệu đúng trong trường hợp thông thường vẫn có thể cho phép dữ liệu không hợp lệ, xử lý sai quyền truy cập hoặc gặp lỗi khi tài nguyên không tồn tại.
Hãy xây dựng bộ kiểm thử dựa trên cả kết quả mong đợi và những hành vi hệ thống phải từ chối. Đối với chức năng quan trọng, cần kiểm thử cả trường hợp biên và các tình huống đồng thời.
Để AI tự quyết định nghiệp vụ chưa được xác định
Nếu không nêu rõ chính sách, AI có thể tự chọn cách xử lý việc xóa dữ liệu, cập nhật giá, tính tồn kho hoặc phân quyền người dùng. Những quyết định này có thể ảnh hưởng trực tiếp đến dữ liệu thực tế.
Với các quy tắc quan trọng, hãy ghi chúng thành yêu cầu cụ thể, yêu cầu AI liệt kê giả định và xác nhận các điểm còn mơ hồ trước khi triển khai.
Chấp nhận mã nguồn mà không đọc lại
Mã nguồn do AI tạo ra có thể sử dụng thư viện không cần thiết, xử lý ngoại lệ quá rộng hoặc lặp lại logic ở nhiều nơi. Nếu không rà soát, những vấn đề này sẽ tích lũy và làm tăng chi phí bảo trì.
Hãy kiểm tra phần thay đổi bằng Git, đọc các đoạn xử lý nghiệp vụ quan trọng và yêu cầu AI giải thích những phần bạn chưa hiểu. Không nên đưa một đoạn mã vào sản xuất chỉ vì nó chạy được trong ví dụ đơn giản.
Nhầm lẫn giữa API chạy được và API sẵn sàng vận hành
Hoàn thành các endpoint mới chỉ là một phần của công việc. API thực tế còn cần cơ chế xác thực, phân quyền, lưu trữ lâu dài, kiểm thử tự động, quản lý cấu hình, giám sát và quy trình phục hồi khi xảy ra sự cố.
Hãy đánh giá mức độ hoàn thiện dựa trên tiêu chí kỹ thuật và nghiệp vụ đã xác định, không dựa trên số lượng dòng mã hoặc số lượng tính năng AI đã tạo.
Checklist hoàn thiện REST API bằng Vibe Coding
Trước khi phát hành, hãy rà soát hệ thống theo các nhóm tiêu chí sau. Không nhất thiết mọi dự án đều cần cùng một mức độ phức tạp, nhưng những yêu cầu về tính đúng đắn, bảo mật và khả năng kiểm soát dữ liệu không nên bị bỏ qua.
Yêu cầu và thiết kế
- Phạm vi chức năng và quy tắc nghiệp vụ đã được xác định rõ.
- Endpoint, phương thức HTTP và cấu trúc dữ liệu nhất quán.
- Mã trạng thái và định dạng phản hồi lỗi đã được thống nhất.
- Những giả định quan trọng do AI đưa ra đã được kiểm tra.
Chất lượng mã nguồn và dữ liệu
- Mã nguồn đã được rà soát và không chứa thay đổi ngoài phạm vi cần thiết.
- Dữ liệu đầu vào được kiểm tra ở phía máy chủ.
- Các thao tác dữ liệu có xử lý phù hợp với yêu cầu giao dịch và tính nhất quán.
- Cấu hình, thư viện phụ thuộc và migration được quản lý rõ ràng.
Kiểm thử và bảo mật
- Kiểm thử chức năng và các trường hợp lỗi đã được thực thi.
- Quyền truy cập được kiểm tra ở phía máy chủ.
- Thông tin bí mật không nằm trong mã nguồn hoặc log công khai.
- Đã xem xét giới hạn tốc độ, kích thước yêu cầu và các rủi ro liên quan.
- Phản hồi lỗi không để lộ thông tin nội bộ không cần thiết.
Triển khai và vận hành
- Cấu hình môi trường phát triển và sản xuất được phân biệt rõ.
- Đã xác định cách khởi động, giám sát và khôi phục dịch vụ.
- Có chiến lược sao lưu và đã kiểm tra khả năng khôi phục dữ liệu.
- Đã xem xét hiệu năng và các giới hạn tài nguyên.
- Có tài liệu hướng dẫn cài đặt, chạy, kiểm thử và sử dụng API.
Kết luận
Vibe Coding giúp quá trình xây dựng REST API trở nên nhanh và dễ tiếp cận hơn nhờ khả năng chuyển yêu cầu bằng ngôn ngữ tự nhiên thành mã nguồn, kiểm thử và tài liệu kỹ thuật. Tuy nhiên, hiệu quả thực sự không nằm ở việc AI tạo được bao nhiêu dòng mã, mà ở khả năng biến yêu cầu thành một hệ thống đúng nghiệp vụ, dễ kiểm thử và có thể bảo trì.
Quy trình phù hợp là bắt đầu từ một bài toán cụ thể, xác định hợp đồng API, chia nhỏ công việc, yêu cầu AI triển khai từng phần rồi kiểm tra bằng các trường hợp thực tế. Khi chức năng cơ bản đã ổn định, hãy tiếp tục bổ sung cơ sở dữ liệu, xác thực, phân quyền, kiểm thử tự động và các yêu cầu vận hành.
Điều quan trọng nhất là luôn giữ quyền kiểm soát đối với mã nguồn. Hãy xem AI như một cộng sự hỗ trợ phát triển, không phải nguồn bảo đảm rằng mọi quyết định kỹ thuật đều chính xác. Khi kết hợp tốc độ của AI với quy trình kiểm chứng nghiêm túc, bạn có thể xây dựng REST API hiệu quả hơn mà vẫn duy trì chất lượng và khả năng kiểm soát hệ thống.
Nếu cần xây dựng REST API phục vụ website hoặc tích hợp với hệ thống hiện có, Web Mới cung cấp dịch vụ lập trình web code tay PHP theo yêu cầu, với giá website từ 6 triệu đồng. Việc xác định đúng kiến trúc, chức năng và yêu cầu bảo mật ngay từ đầu sẽ giúp dự án dễ mở rộng và phù hợp hơn với nhu cầu vận hành thực tế.
- 0 Bình luận
Email, Điện thoại của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *
