API là hợp đồng (contract) giữa Frontend và Backend — thiết kế tồi khiến cả 2 phía phải làm việc vòng vèo để bù đắp. Nhà tuyển dụng dùng câu hỏi này để kiểm tra tư duy thiết kế hệ thống, không chỉ khả năng viết code.
GET /users/123 đúng, GET /getUser?id=123 không theo chuẩn REST."Thiết kế API cho tính năng phân trang (pagination), cần cân nhắc gì?" — So sánh offset-based pagination (?page=2&limit=20, đơn giản nhưng dễ bug khi dữ liệu thay đổi giữa các lần gọi) với cursor-based pagination (?cursor=abc123, ổn định hơn với dữ liệu thay đổi liên tục nhưng phức tạp hơn để implement) — chọn loại nào tuỳ đặc điểm dữ liệu và yêu cầu UX.
"API trả về lỗi, format response nên như thế nào?" — Nhất quán cấu trúc lỗi (vd. luôn có { statusCode, message, error }) giúp Frontend xử lý lỗi dễ dàng ở 1 chỗ tập trung, thay vì mỗi endpoint 1 kiểu.
"Versioning API khi cần thay đổi breaking change, làm thế nào?" — Phổ biến nhất là version trong URL (/v1/users, /v2/users) — dễ hiểu, dễ route. Header-based versioning linh hoạt hơn nhưng khó debug/test hơn với công cụ thông thường.
Khi Frontend cần dữ liệu lồng nhau (vd. danh sách bài viết kèm thông tin tác giả), thiết kế API tệ buộc Frontend gọi 1 API lấy danh sách rồi N API riêng lấy từng tác giả — giải pháp: thiết kế endpoint trả về sẵn dữ liệu liên quan (JOIN ở Backend) hoặc dùng GraphQL nếu nhu cầu truy vấn linh hoạt phức tạp.
Khi thiết kế API trong buổi phỏng vấn, hãy hỏi rõ use case thực tế trước khi vẽ ra endpoint — thể hiện bạn thiết kế API theo nhu cầu sử dụng thật, không theo khuôn mẫu CRUD máy móc.