API Design: Xây dựng Giao diện Lập trình Chuyên nghiệp

Trả lời: Representational State Transfer. Là một phong cách kiến trúc sử dụng các phương thức HTTP (GET, POST, PUT, DELETE) để thao tác với tài nguyên (Resources) qua URL.

Trả lời: Nên dùng danh từ số nhiều. Ví dụ: /users, /orders thay vì /getUser hoặc /all-orders.

Trả lời: Để Client biết nhanh kết quả mà không cần đọc nội dung: 200 (OK), 201 (Created), 400 (Bad Request), 404 (Not Found), 500 (Server Error).

Trả lời: JavaScript Object Notation. Nó nhẹ, dễ đọc cho cả người và máy, và được hầu hết các ngôn ngữ lập trình hỗ trợ.

Trả lời:

• Path: Dùng để xác định 1 tài nguyên cụ thể.
• Query: Dùng để lọc, sắp xếp hoặc phân trang danh sách tài nguyên.

Trả lời: Là tài liệu hướng dẫn cách sử dụng API (endpoint, tham số, dữ liệu trả về). Công cụ phổ biến nhất là Swagger/OpenAPI.

Trả lời: Mỗi request từ client phải chứa đầy đủ thông tin để server hiểu và xử lý, server không lưu giữ “trạng thái” của client giữa các lần gọi.

Trả lời: Là phần thân (Body) chứa dữ liệu thực tế được gửi lên server, thường dùng cho POST, PUT, PATCH.

Trả lời: Là một chuỗi định danh để server biết client nào đang gọi và có quyền truy cập hay không.

Trả lời:

• Public: Bất kỳ ai cũng có thể sử dụng (thường cần đăng ký).
• Private: Chỉ dùng nội bộ trong công ty hoặc giữa các service của chính mình.

Trả lời: Để không làm hỏng các client cũ khi API thay đổi. Cách làm: URL (/v1/users), Header (Accept: v1), hoặc Query string (?version=1).

Trả lời: Một API là lũy đẳng nếu gọi nhiều lần với cùng dữ liệu thì kết quả trên hệ thống vẫn như gọi 1 lần (GET, PUT, DELETE là lũy đẳng; POST thì không).

Trả lời: Hypermedia as the Engine of Application State. Server trả về dữ liệu kèm theo các đường link dẫn tới các hành động tiếp theo có thể thực hiện.

Trả lời: Dùng page & limit (Offset-based) hoặc cursor (Cursor-based). Cursor-based tốt hơn cho dữ liệu lớn và thay đổi liên tục.

Trả lời: Nên trả về một object có cấu trúc thống nhất: error_code, message, và details (nếu cần cho validation).

Trả lời: Dùng thuật toán Token Bucket hoặc Leaky Bucket. Trả về lỗi 429 (Too Many Requests) kèm header Retry-After.

Trả lời:

• PUT: Thay thế toàn bộ tài nguyên (nếu thiếu trường sẽ bị null/default).
• PATCH: Chỉ cập nhật các trường được gửi lên (giữ nguyên các trường khác).

Trả lời: Dùng header Accept-Language hoặc tham số query ?lang=vi.

Trả lời: Dùng query string rõ ràng. Ví dụ: ?status=active&sort=-created_at (dấu trừ đại diện cho DESC).

Trả lời: Client gửi username/pass -> Server trả về Token -> Client lưu và đính kèm Token vào Header Authorization: Bearer <token> cho mọi request sau.

Trả lời: Chọn GraphQL khi Client cần lấy dữ liệu phức tạp từ nhiều nguồn trong 1 request và muốn tránh Over-fetching. Đánh đổi: Caching phức tạp hơn, rủi ro query quá nặng làm sập server.

Trả lời: Dùng HTTP/2 và Protocol Buffers (Binary format). Dữ liệu được nén nhỏ, truyền nhanh, hỗ trợ streaming 2 chiều và Strong typing.

Trả lời: Server bắn request tới Client khi có sự kiện. An toàn: Dùng X-Hub-Signature (HMAC) để client xác thực request thực sự đến từ server mình.

Trả lời: Trả về 202 Accepted kèm job_id. Client sẽ polling vào endpoint /jobs/{id} để kiểm tra trạng thái hoặc server bắn Webhook khi xong.

Trả lời: Là cổng vào duy nhất, chịu trách nhiệm: Routing, Authentication, Rate Limiting, Logging, và Response Aggregation (gộp data từ nhiều service).

Trả lời: Nhận một mảng các operations. Cần quyết định xem nếu 1 cái lỗi thì có rollback tất cả (Atomic) hay vẫn xử lý các cái khác (Partial success).

Trả lời: Client gửi kèm 1 key duy nhất. Nếu server nhận được 2 request cùng key, nó sẽ trả về kết quả của lần đầu thay vì thực hiện giao dịch lần 2.

Trả lời: Dùng Eager loading, Caching (Redis), Gzip compression, và giảm thiểu số lượng Join trong database.

Trả lời: Internal có thể dùng mTLS, tin tưởng lẫn nhau hơn. External cần OAuth2, Rate limit gắt gao, và tài liệu cực kỳ chi tiết.

Trả lời: Viết tài liệu (OpenAPI spec) trước khi viết code. Giúp team Frontend và Backend có thể làm việc song song dựa trên “hợp đồng” đã chốt.

Trả lời: Dùng Edge Computing/CDN để cache response. Triển khai API Gateway đa vùng (Multi-region). Dùng cơ chế Token-based Auth stateless để dễ scale ngang.

Trả lời: Hỗ trợ song song cả 2 version. Dùng Adapter layer để map dữ liệu cũ sang mới. Monitor traffic và dần dần tắt version cũ sau khi thông báo cho client.

Trả lời: Tạo các service riêng cho từng loại client (Mobile, Web, IoT) để tối ưu hóa payload và logic phù hợp nhất cho từng thiết bị.

Trả lời: Dùng Istio/Linkerd. Tách biệt logic hạ tầng (Retries, Circuit breaker, Auth) ra khỏi mã nguồn ứng dụng qua Sidecar proxy.

Trả lời: Thay vì Request-Response truyền thống, hệ thống giao tiếp qua Events. Dùng AsyncAPI để mô tả các message, channel giúp hệ thống cực kỳ linh hoạt và chịu tải tốt.

Xử lý: 1. Triển khai tham số ?fields=id,name để client tự chọn cột. 2. Hoặc xây dựng GraphQL layer. 3. Hoặc dùng BFF để trả về payload thu gọn.

Xử lý: 1. Implement Rate Limiting theo IP và Username. 2. Bật cơ chế Account Lockout sau 5 lần sai. 3. Trả về mã lỗi chung (không báo là sai pass hay sai user).