Câu Hỏi Phỏng Vấn REST API và Đáp Án (Hướng Dẫn 2026)

REST API vận hành phần lớn các tích hợp trên internet. Dù bạn ứng tuyển vai trò backend, full stack hay kỹ sư phần mềm, nhiều khả năng bạn sẽ gặp các câu hỏi về thiết kế REST API, phương thức HTTP và các mẫu xác thực.

Trong hướng dẫn này, tôi sẽ dẫn bạn qua những câu hỏi nhà tuyển dụng thực sự hay hỏi. Tôi đã sắp xếp chúng theo mức độ khó và loại vai trò, để bạn tập trung vào những gì quan trọng nhất cho vị trí mục tiêu. Mỗi câu trả lời đều kèm ví dụ thực tế và, khi phù hợp, các đoạn mã bạn có thể điều chỉnh.

Một điều cần nhớ: nhà tuyển dụng kiểm tra nền tảng cơ bản thường xuyên hơn nhiều so với các chủ đề nâng cao. Nếu bạn nắm chắc những điều căn bản (phương thức HTTP, mã trạng thái, tính vô trạng), bạn sẽ tự tin xử lý hầu hết các buổi phỏng vấn REST API. Những mẫu kiến trúc cầu kỳ sẽ đến sau.

Câu hỏi Phỏng vấn REST API Cơ bản

Những câu hỏi này kiểm tra kiến thức nền tảng của bạn. Hãy kỳ vọng gặp chúng trong hầu như mọi buổi phỏng vấn, bất kể cấp độ thâm niên.

1. REST là gì và các ràng buộc của nó?

REST là viết tắt của Representational State Transfer. Đây là một phong cách kiến trúc để thiết kế các ứng dụng mạng, được Roy Fielding định nghĩa trong luận án tiến sĩ năm 2000.

REST có sáu ràng buộc:

1. Client-Server: Tách biệt giữa giao diện người dùng và lưu trữ dữ liệu
2. Stateless: Mỗi yêu cầu chứa đầy đủ thông tin cần để hoàn thành
3. Cacheable: Phản hồi phải chỉ rõ có thể được lưu đệm hay không
4. Layered System: Các thành phần không thể nhìn vượt quá lớp liền kề
5. Uniform Interface: Cách thức chuẩn hóa để tương tác với tài nguyên
6. Code-on-Demand (tùy chọn): Máy chủ có thể gửi mã thực thi tới máy khách

2. Sự khác nhau giữa REST và SOAP là gì?

REST là một phong cách kiến trúc; SOAP là một giao thức. REST thường dùng JSON qua HTTP và tận dụng các phương thức HTTP tiêu chuẩn. SOAP chỉ dùng XML và định nghĩa định dạng thông điệp riêng với phong bì và headers.

SOAP vẫn có ý nghĩa với các hệ thống doanh nghiệp cần hợp đồng chính thức (WSDL) hoặc bảo mật cấp thông điệp (WS-Security).

3. Các phương thức HTTP là gì và dùng khi nào?

Các phương thức HTTP xác định hành động cần thực hiện trên một tài nguồn.

4. Sự khác nhau giữa PUT và POST là gì?

POST tạo một tài nguyên mới, nơi máy chủ quyết định URI. PUT thay thế một tài nguyên tại một URI cụ thể do máy khách chỉ định.

POST /users          → Server creates user, returns /users/123
PUT /users/123       → Client specifies URI, replaces entire resource

Nếu bạn PUT tới một URI chưa tồn tại, máy chủ có thể tạo mới. Nếu bạn PUT tới một URI đã tồn tại, bạn sẽ thay thế toàn bộ tài nguyên.

5. Sự khác nhau giữa PUT và PATCH là gì?

PUT thay thế toàn bộ tài nguyên. PATCH áp dụng các sửa đổi từng phần.

# PUT replaces everything
PUT /users/123
{"name": "Khalid", "email": "khalid@example.com", "role": "admin"}

# PATCH updates only specified fields
PATCH /users/123
{"role": "admin"}

6. "Stateless" trong REST nghĩa là gì?

Stateless nghĩa là mỗi yêu cầu phải chứa toàn bộ thông tin máy chủ cần để xử lý. Máy chủ không lưu bất kỳ ngữ cảnh khách hàng nào giữa các yêu cầu.

Điều này đồng nghĩa không có session phía máy chủ. Nếu người dùng đã xác thực, máy khách phải gửi thông tin xác thực (thường là token) trong mọi yêu cầu.

7. Điều gì làm cho một API là RESTful?

Một API thực sự RESTful khi thỏa mãn tất cả ràng buộc REST, bao gồm HATEOAS (Hypermedia as the Engine of Application State). Trên thực tế, hầu hết API tự nhận là "REST" thực ra là "giống REST" hoặc ở Mức 2 của Mô hình Trưởng thành Richardson. Và thành thật mà nói, điều đó là ổn cho đa số trường hợp.

Các mức trong Mô hình Trưởng thành Richardson cho REST API. Hình do Tác giả thực hiện.

8. Những mã trạng thái HTTP cơ bản nào bạn nên biết?

Bạn nên quen thuộc với ít nhất bảy mã trạng thái thiết yếu này, bao quát phần lớn tình huống API:

9. Sự khác nhau giữa tài nguyên và endpoint là gì?

Tài nguyên là thực thể dữ liệu (người dùng, đơn hàng, sản phẩm). Endpoint là đường dẫn URL cung cấp quyền truy cập tới tài nguyên đó.

Resource: User
Endpoints: GET /users, GET /users/123, POST /users

10. Thực hành tốt cho thiết kế URI là gì?

Dùng danh từ, không dùng động từ. Để URI viết thường với dấu gạch nối cho tên nhiều từ. Dùng danh từ số nhiều cho tập hợp.

Good:  /users, /users/123, /order-items
Bad:   /getUsers, /Users, /order_items

Tránh lồng quá sâu. Thay vì /users/123/posts/456/comments/789, hãy cân nhắc /comments/789 hoặc /comments?post_id=456.

11. Tính idempotent là gì và những phương thức HTTP nào là idempotent?

Một thao tác là idempotent nếu thực hiện nhiều lần cho ra kết quả giống như thực hiện một lần.

Một PATCH đặt một giá trị là idempotent; một PATCH tăng bộ đếm thì không.

12. Sự khác nhau giữa phương thức an toàn (safe) và idempotent?

Phương thức an toàn không sửa đổi tài nguyên (GET, HEAD, OPTIONS). Phương thức idempotent có thể gọi nhiều lần với cùng hiệu ứng (GET, PUT, DELETE).

Tất cả phương thức an toàn đều idempotent, nhưng không phải mọi phương thức idempotent đều an toàn. DELETE là idempotent nhưng không an toàn vì nó sửa đổi trạng thái.

13. Khi nào dùng tham số truy vấn so với tham số đường dẫn?

Tham số đường dẫn định danh một tài nguyên cụ thể. Tham số truy vấn lọc, sắp xếp hoặc phân trang tập hợp.

Path:   /users/123              (specific user)
Query:  /users?status=active    (filtered collection)
        /users?sort=name&limit=10

14. Đàm phán nội dung (content negotiation) là gì?

Đàm phán nội dung cho phép máy khách yêu cầu các biểu diễn khác nhau của một tài nguyên. Máy khách gửi header Accept, và máy chủ phản hồi với định dạng phù hợp.

Accept: application/json    → Server returns JSON
Accept: application/xml     → Server returns XML

15. Mục đích của phương thức OPTIONS là gì?

OPTIONS trả về các phương thức HTTP mà máy chủ hỗ trợ cho một URL cụ thể. Trình duyệt dùng nó cho yêu cầu thăm dò CORS để kiểm tra có cho phép yêu cầu cross-origin hay không.

Câu hỏi Phỏng vấn REST API Trung cấp

Những câu hỏi này kiểm tra khả năng ứng dụng thực tế và ra quyết định. Hãy kỳ vọng cho vị trí tầm trung.

16. Sự khác nhau giữa 401 và 403?

Đây là cặp mã trạng thái hay bị nhầm nhất. Tôi đã thấy cả kỹ sư cao cấp cũng lẫn lộn trong các buổi review mã.

401 Unauthorized

Nghĩa là chưa xác thực. Máy chủ không biết bạn là ai. Phản hồi của bạn nên nhắc người dùng đăng nhập.

403 Forbidden

Nghĩa là không được phép. Máy chủ biết bạn là ai nhưng bạn thiếu quyền. Xác thực lại cũng không giúp gì.

Lưu đồ quyết định lỗi xác thực so với phân quyền. Hình do Tác giả thực hiện.

17. Sự khác nhau giữa 400 và 422?

Dưới đây là ví dụ minh họa sự khác biệt:

400 Bad Request

Chỉ ra cú pháp sai. Máy chủ không thể phân tích yêu cầu (cấu trúc JSON không hợp lệ, thiếu header bắt buộc).

422 Unprocessable Entity

Chỉ ra cú pháp hợp lệ nhưng lỗi ngữ nghĩa. JSON hợp lệ nhưng dữ liệu không qua xác thực (định dạng email sai, mật khẩu quá ngắn).

# 400: Cannot parse
{"name": "Khalid",}  # Trailing comma breaks JSON

# 422: Valid JSON, invalid data
{"email": "not-an-email"}  # Fails validation

18. Khi nào dùng 409 Conflict?

Dùng 409 khi yêu cầu xung đột với trạng thái hiện tại của tài nguyên:

• Thất bại khóa lạc quan (ETag không khớp)
• Vi phạm ràng buộc duy nhất (tên người dùng trùng)
• Chuyển trạng thái không hợp lệ (hủy đơn hàng đã giao)

19. Bạn triển khai phân trang thế nào?

Hai cách tiếp cận chính:

Phân trang dựa trên offset

Đơn giản nhưng gặp vấn đề hiệu năng với tập dữ liệu lớn.

GET /users?limit=20&offset=40

Phân trang dựa trên cursor

Mở rộng tốt hơn và tránh "trôi trang" khi dữ liệu thay đổi.

GET /users?limit=20&cursor=eyJpZCI6MTIzfQ

Các công ty như Stripe, GitHub và Slack dùng phân trang theo cursor cho tập dữ liệu lớn.

20. Các chiến lược quản lý phiên bản API phổ biến?

Có ba cách tiếp cận chính, mỗi cách có đánh đổi khác nhau:

Phiên bản trong URI

Phổ biến nhất. Rõ ràng và dễ debug.

GET /v1/users
GET /v2/users

Phiên bản qua header

URL gọn hơn nhưng khó thử trong trình duyệt.

GET /users
Accept-Version: v2

Phiên bản qua tham số truy vấn

Dễ thêm nhưng làm URL lộn xộn.

GET /users?version=2

21. ETag là gì và bộ nhớ đệm hoạt động thế nào?

ETag là định danh phiên bản cho một tài nguyên. Máy chủ gửi nó trong phản hồi; máy khách gửi lại trong các yêu cầu sau để kiểm tra tài nguyên có thay đổi không.

# First request
GET /users/123
Response: ETag: "abc123"

# Subsequent request
GET /users/123
If-None-Match: "abc123"
Response: 304 Not Modified (if unchanged)

22. Những phương thức xác thực nào dùng cho REST API?

Bốn phương thức xác thực phổ biến là API Key, Bearer Token, OAuth 2.0 và JWT:

23. JWT là gì và hoạt động ra sao?

JWT (JSON Web Token) gồm ba phần: Header, Payload và Signature. Tìm hiểu thêm về làm việc với JSON trong Python.

Header: {"alg": "RS256", "typ": "JWT"}
Payload: {"sub": "user123", "exp": 1704153600}
Signature: RSASHA256(base64(header) + "." + base64(payload), privateKey)

Máy chủ ký token; máy khách gửi kèm trong yêu cầu. Máy chủ xác thực chữ ký mà không cần tra cứu cơ sở dữ liệu.

24. Sự khác nhau giữa RS256 và HS256?

HS256 (đối xứng): Cùng một bí mật dùng để ký và xác minh. Rủi ro nếu nhiều dịch vụ cần xác minh token.

RS256 (bất đối xứng): Khóa riêng ký, khóa công khai xác minh. Khuyến nghị cho hệ thống phân tán nơi nhiều dịch vụ xác thực token.

25. HATEOAS là gì?

HATEOAS (Hypermedia as the Engine of Application State) nghĩa là phản hồi bao gồm các liên kết tới hành động và tài nguyên liên quan.

{
  "id": 123,
  "name": "Khalid",
  "links": [
    {"rel": "self", "href": "/users/123"},
    {"rel": "orders", "href": "/users/123/orders"}
  ]
}

Trên thực tế, đa số API không triển khai đầy đủ HATEOAS. Hãy biết khái niệm này nhưng đừng kỳ vọng phải triển khai trong hầu hết công việc. Ngay cả các công ty công nghệ lớn cũng hiếm khi xây dựng API tuân thủ HATEOAS hoàn toàn.

26. Bạn xử lý lỗi nhất quán như thế nào?

Dùng định dạng RFC 7807 Problem Details cho phản hồi lỗi nhất quán:

{
  "type": "https://api.example.com/errors/validation",
  "title": "Validation Error",
  "status": 422,
  "detail": "Email format is invalid",
  "instance": "/users"
}

27. Hạn chế tốc độ (rate limiting) là gì và vì sao quan trọng?

Rate limiting bảo vệ API khỏi lạm dụng và đảm bảo sử dụng công bằng. Phản hồi phổ biến:

HTTP/1.1 429 Too Many Requests
Retry-After: 3600
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 0

28. Bạn thiết kế lọc và sắp xếp thế nào?

Dùng tham số truy vấn với quy ước rõ ràng:

# Filtering
GET /products?category=electronics&price[gte]=100&price[lte]=500

# Sorting (prefix - for descending)
GET /users?sort=-created_at,name

Câu hỏi Phỏng vấn REST API Nâng cao

Những câu hỏi này kiểm tra tư duy kiến trúc. Hãy kỳ vọng cho vị trí cấp cao.

29. Có gì thay đổi giữa OAuth 2.0 và OAuth 2.1?

OAuth 2.1 hợp nhất các thực hành bảo mật tốt nhất:

Điểm mấu chốt: dùng luồng Authorization Code với PKCE cho mọi loại client.

30. Bạn triển khai idempotency cho endpoint thanh toán thế nào?

Dùng idempotency key để khiến yêu cầu POST an toàn khi retry:

async def handle_payment(request: Request, payment: PaymentCreate):
    idempotency_key = request.headers.get("Idempotency-Key")
    
    # Check if already processed
    cached = await redis.get(f"idem:{idempotency_key}")
    if cached:
        return JSONResponse(json.loads(cached))
    
    # Process payment
    result = await process_payment(payment)
    
    # Cache result (24-hour TTL)
    await redis.setex(f"idem:{idempotency_key}", 86400, json.dumps(result))
    return result

Máy khách tạo một UUID và gửi kèm theo yêu cầu. Nếu cùng key đến lần nữa, trả về phản hồi đã lưu.

31. Bạn thiết kế rate limiter phân tán như thế nào?

Với hệ thống phân tán, bạn không thể dùng bộ đếm trong bộ nhớ vì lưu lượng được cân bằng qua nhiều instance. Đây là cạm bẫy thường làm ứng viên vấp ngã.

Kiến trúc:

1. Dùng Redis để lưu trữ bộ đếm tập trung
2. Triển khai thuật toán Token Bucket để chịu bùng nổ
3. Dùng thao tác nguyên tử (Lua script) để tránh điều kiện tranh chấp

# Pseudocode for Token Bucket
tokens = redis.get(user_id) or max_tokens
if tokens > 0:
    redis.decr(user_id)
    process_request()
else:
    return 429

32. Khi nào bạn chọn gRPC thay vì REST?

Chọn gRPC khi:

• Giao tiếp nội bộ microservice (thông lượng tăng 5-10 lần)
• Yêu cầu streaming thời gian thực
• Mobile-to-backend với băng thông hạn chế
• Môi trường đa ngôn ngữ cần hợp đồng nghiêm ngặt

Chọn REST khi:

• API công khai với nhiều đối tượng sử dụng
• Ứng dụng web (hỗ trợ trình duyệt phổ quát)
• CRUD đơn giản
• Nhóm chưa quen với Protocol Buffers

33. Bạn xử lý tác vụ chạy lâu như thế nào?

Dùng mẫu yêu cầu bất đồng bộ:

1. Máy khách gửi yêu cầu

2. Máy chủ trả về 202 Accepted kèm URL trạng thái

3. Máy khách thăm dò URL trạng thái đến khi hoàn tất

POST /reports
Response: 202 Accepted
Location: /reports/abc123/status

GET /reports/abc123/status
Response: {"status": "processing", "progress": 45}

GET /reports/abc123/status
Response: {"status": "completed", "result_url": "/reports/abc123"}

34. Mẫu (pattern) Saga là gì?

Saga xử lý giao dịch phân tán trên nhiều microservice mà không cần khóa. Mỗi dịch vụ thực hiện một giao dịch cục bộ và phát sự kiện. Nếu một bước thất bại, các giao dịch bù hoàn tác các bước trước.

Order Created → Payment Processed → Inventory Reserved → Order Confirmed
                     ↓ (failure)
              Release Payment → Cancel Order

35. Các lỗ hổng bảo mật JWT phổ biến?

Nhầm lẫn thuật toán: Kẻ tấn công đổi RS256 sang HS256 và ký bằng khóa công khai. Cách khắc phục: luôn whitelist thuật toán.

# Vulnerable
jwt.decode(token, key)

# Secure
jwt.decode(token, key, algorithms=["RS256"])

Thuật toán "none": Kẻ tấn công loại bỏ hoàn toàn chữ ký. Cách khắc phục: từ chối thuật toán "none".

Câu hỏi REST API cho Lập trình viên Backend

36. Vấn đề truy vấn N+1 là gì?

Vấn đề N+1 xảy ra khi bạn lấy N bản ghi rồi thực hiện một truy vấn riêng cho từng quan hệ của mỗi bản ghi.

# N+1 Problem: 101 queries for 100 users
users = User.query.all()  # 1 query
for user in users:
    print(user.posts)     # 100 queries

Giải pháp:

Django: Dùng select_related() cho khóa ngoại, prefetch_related() cho quan hệ nhiều-nhiều.

# 2 queries instead of 101
users = User.objects.prefetch_related('posts').all()

SQLAlchemy: Dùng joinedload() hoặc selectinload().

37. Bạn cấu hình connection pooling như thế nào?

Connection pooling tái sử dụng kết nối cơ sở dữ liệu thay vì tạo mới cho mỗi yêu cầu.

# SQLAlchemy
engine = create_engine(
    "postgresql://user:pass@host/db",
    pool_size=5,           # Permanent connections
    max_overflow=10,       # Temporary overflow
    pool_timeout=30,       # Wait timeout
    pool_pre_ping=True     # Validate before use
)

38. Bạn biết những chiến lược lưu đệm nào?

Có ba chiến lược lưu đệm chính, mỗi chiến lược tối ưu cho kiểu truy cập khác nhau:

39. Bạn triển khai xác minh chữ ký webhook như thế nào?

import hmac
import hashlib

def verify_webhook(payload: bytes, signature: str, secret: str) -> bool:
    expected = 'sha256=' + hmac.new(
        secret.encode(),
        payload,
        hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(expected, signature)

40. Những chỉ số nào cho thấy sức khỏe API?

Bạn nên giám sát bốn chỉ số then chốt này để đánh giá sức khỏe API:

Câu hỏi REST API cho Lập trình viên Full Stack

41. Khi nào trình duyệt gửi yêu cầu thăm dò CORS?

Trình duyệt gửi OPTIONS preflight khi:

• Phương thức khác GET, HEAD, POST
• Header tùy chỉnh (Authorization, X-API-Key)
• Content-Type khác form-urlencoded, multipart/form-data, text/plain

42. Bạn cấu hình CORS an toàn như thế nào?

// Express.js
app.use(cors({
  origin: ['https://yourdomain.com'],  // Never use * with credentials
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization']
}));

Không bao giờ dùng wildcard (*) với thông tin xác thực. Không bao giờ cho phép null origin.

43. Bạn nên lưu token ở đâu trên máy khách?

Lưu trữ token liên quan đến đánh đổi bảo mật giữa lỗ hổng XSS và CSRF"

Thực hành tốt nhất: Lưu refresh token trong cookie HttpOnly với SameSite=Strict. Giữ access token trong bộ nhớ.

44. Khi nào dùng WebSockets so với SSE?

Lựa chọn phụ thuộc vào việc bạn có cần giao tiếp hai chiều hay không và cách bạn muốn xử lý kết nối lại:

Dùng SSE cho thông báo, luồng trực tiếp, bảng giá cổ phiếu. Dùng WebSockets cho chat, game nhiều người, soạn thảo cộng tác.

45. Bạn xử lý tải lên tệp như thế nào?

Với tệp lớn, dùng tải lên theo khối (chunk) kèm theo theo dõi tiến độ:

async function chunkedUpload(file, chunkSize = 5 * 1024 * 1024) {
  const totalChunks = Math.ceil(file.size / chunkSize);
  
  for (let i = 0; i < totalChunks; i++) {
    const chunk = file.slice(i * chunkSize, (i + 1) * chunkSize);
    await uploadChunk(uploadId, i, chunk);
  }
}

Câu hỏi REST API theo Kịch bản

46. Thiết kế REST API cho hệ thống đặt phòng khách sạn

Tài nguyên:

• /hotels - Liệt kê và tìm kiếm khách sạn

• /hotels/{id}/rooms - Phòng còn trống

• /bookings - Tạo và quản lý đặt chỗ

• /guests/{id} - Hồ sơ khách

Quyết định chính:

• Dùng phân trang theo cursor cho tìm kiếm khách sạn
• Triển khai khóa lạc quan cho tình trạng phòng
• Trả về 409 Conflict khi cố đặt trùng
• Dùng idempotency key cho xử lý thanh toán

47. Bạn sẽ triển khai xóa mềm (soft delete) như thế nào?

Thêm timestamp deleted_at thay vì xóa bản ghi:

@app.delete("/users/{user_id}")
def delete_user(user_id: int):
    user = db.get(user_id)
    user.deleted_at = datetime.utcnow()
    db.commit()
    return Response(status_code=204)

@app.get("/users")
def list_users(include_deleted: bool = False):
    query = User.query
    if not include_deleted:
        query = query.filter(User.deleted_at.is_(None))
    return query.all()

48. Bạn di trú từ v1 sang v2 mà không làm hỏng client như thế nào?

Dùng mẫu Cây Đa Bóp Nghẹt (Strangler Fig):

1. Triển khai v2 song song với v1
2. Định tuyến tính năng mới sang v2
3. Di trú dần các endpoint hiện có
4. Thông báo ngừng hỗ trợ qua header Sunset
5. Gỡ v1 sau thời gian di trú

49. Bạn thiết kế API tìm kiếm với lọc phức tạp như thế nào?

Với tìm kiếm sản phẩm có nhiều bộ lọc:

GET /products?q=laptop&category=electronics&price[gte]=500&price[lte]=2000&brand=apple,dell&in_stock=true&sort=-rating&limit=20&cursor=abc123

Quyết định thiết kế:

• Dùng Elasticsearch cho full-text search (CSDL quan hệ khó xử lý so khớp mờ)
• Triển khai tìm kiếm theo tiêu chí (faceted) để hiển thị tùy chọn lọc sẵn có
• Trả về số lượng theo bộ lọc để người dùng biết mỗi bộ lọc cho ra bao nhiêu kết quả
• Lưu đệm các tổ hợp tìm kiếm phổ biến

50. Bạn xử lý quản lý phiên bản API trong kiến trúc microservices như thế nào?

Tùy chọn:

1. Phiên bản ở cấp gateway: API gateway định tuyến /v1/* tới dịch vụ cũ, /v2/* tới dịch vụ mới

2. Phiên bản ở cấp dịch vụ: Mỗi dịch vụ tự xử lý thương lượng phiên bản

3. Hợp đồng do bên tiêu thụ chi phối: Dùng Pact hoặc công cụ tương tự để đảm bảo tương thích

Với đa số nhóm, phiên bản ở cấp gateway mang lại sự tách biệt gọn gàng nhất.

51. Bạn sẽ triển khai rate limiting cho các hạng người dùng khác nhau như thế nào?

Giải pháp gồm định nghĩa giới hạn theo hạng và kiểm tra bằng bộ đếm Redis:

RATE_LIMITS = {
    "free": {"requests": 100, "window": 3600},
    "pro": {"requests": 1000, "window": 3600},
    "enterprise": {"requests": 10000, "window": 3600}
}

async def rate_limit_middleware(request: Request):
    user = get_current_user(request)
    tier = user.subscription_tier
    limits = RATE_LIMITS[tier]
    
    key = f"rate:{user.id}:{current_hour()}"
    count = await redis.incr(key)
    
    if count == 1:
        await redis.expire(key, limits["window"])
    
    if count > limits["requests"]:
        raise HTTPException(
            status_code=429,
            headers={
                "X-RateLimit-Limit": str(limits["requests"]),
                "X-RateLimit-Remaining": "0",
                "Retry-After": str(seconds_until_reset())
            }
        )

Câu hỏi Hành vi về REST API

52. Giải thích REST cho người không kỹ thuật

"Hãy nghĩ REST API như một người bồi bàn trong nhà hàng. Bạn (khách) không thể vào bếp trực tiếp. Thay vào đó, bạn nói với bồi bàn bạn muốn gì từ thực đơn, và họ mang đến cho bạn. Thực đơn giống như tài liệu API, liệt kê những gì bạn có thể gọi. Bồi bàn theo quy tắc cụ thể: bạn yêu cầu món (GET), bạn đặt món mới (POST), hoặc bạn trả lại món (DELETE). Nếu bếp hết món gì đó, bồi bàn sẽ báo bạn (404 Not Found) để bạn không chờ vô ích."

Phép so sánh này hoạt động đáng ngạc nhiên trong các buổi họp với stakeholder.

53. Mô tả một lần bạn tối ưu một API

Dùng phương pháp STAR:

• Tình huống: "API tìm kiếm của chúng tôi có thời gian phản hồi 3 giây lúc cao điểm"
• Nhiệm vụ: "Tôi cần giảm độ trễ mà không thay đổi lớn kiến trúc"
• Hành động: "Tôi thêm Redis caching cho các truy vấn thường gặp, triển khai phân trang theo cursor và thêm index cơ sở dữ liệu"
• Kết quả: "Thời gian phản hồi giảm còn 200ms, và chúng tôi xử lý nhiều hơn gấp 5 lần lưu lượng"

54. Bạn truyền thông các thay đổi phá vỡ (breaking changes) tới người dùng API như thế nào?

1. Thông báo sớm: Cho biết trước ít nhất 6-12 tháng với thay đổi lớn

2. Dùng header Sunset: Sunset: Sat, 31 Dec 2026 23:59:59 GMT

3. Cung cấp hướng dẫn di trú: Tài liệu chính xác thay đổi gì và cách thích ứng

4. Chạy song song hai phiên bản: Giữ phiên bản cũ trong giai đoạn chuyển tiếp

5. Theo dõi sử dụng: Theo dõi client còn dùng phiên bản cũ

55. Bạn tạo những tài liệu gì cho API?

Tài liệu thiết yếu gồm:

• Đặc tả OpenAPI/Swagger: Hợp đồng máy đọc được
• Hướng dẫn bắt đầu: Gọi API đầu tiên trong dưới 5 phút
• Hướng dẫn xác thực: Cách lấy và dùng thông tin xác thực
• Tham chiếu lỗi: Tất cả mã lỗi có thể có và cách xử lý
• Changelog: Thay đổi gì ở mỗi phiên bản
• Tài liệu giới hạn tốc độ: Giới hạn theo hạng và cách xử lý 429

56. Khi nào bạn KHÔNG dùng REST?

REST không phải lúc nào cũng là lựa chọn đúng. Biết khi nào dùng giải pháp thay thế cho thấy sự trưởng thành về kiến trúc. Tôi đã thấy các nhóm ép REST vào các trường hợp gây rắc rối nhiều hơn là giải quyết vấn đề.

Tham Khảo Nhanh REST API

Dùng phần này như tra cứu nhanh khi bạn cần xác minh thuộc tính phương thức HTTP, mã trạng thái hoặc các mẫu phổ biến trong lúc chuẩn bị phỏng vấn hay phát triển thực tế.

So sánh Phương thức HTTP

Bảng này tóm tắt các thuộc tính chính của mỗi phương thức HTTP, giúp bạn chọn đúng cho trường hợp sử dụng.

Tham chiếu Mã Trạng thái

Dưới đây là các mã trạng thái HTTP thường dùng nhất, được tổ chức theo nhóm. Tập trung hiểu khi nào dùng mỗi mã thay vì học thuộc toàn bộ đặc tả.

2xx Thành công

• 200 OK: GET, PUT, PATCH thành công
• 201 Created: POST thành công (kèm header Location)
• 204 No Content: DELETE thành công

4xx Lỗi phía khách

• 400 Bad Request: Cú pháp sai
• 401 Unauthorized: Cần xác thực
• 403 Forbidden: Đã xác thực nhưng không có quyền
• 404 Not Found: Tài nguyên không tồn tại
• 409 Conflict: Xung đột trạng thái
• 422 Unprocessable Entity: Lỗi xác thực
• 429 Too Many Requests: Bị giới hạn tốc độ

5xx Lỗi phía máy chủ

• 500 Internal Server Error: Lỗi chung phía máy chủ
• 502 Bad Gateway: Lỗi máy chủ trung gian
• 503 Service Unavailable: Quá tải tạm thời

Những Sai lầm Phổ biến cần Tránh

Ngay cả lập trình viên giàu kinh nghiệm cũng mắc phải. Hãy chú ý các lỗi thường gặp khi thiết kế hoặc triển khai REST API:

• Dùng động từ trong URL (ví dụ, /getUsers thay vì /users)

• Trả về 200 OK cho trạng thái lỗi, khiến xử lý lỗi phía client bị hỏng

• Nhầm 401 và 403 (Xác thực vs. Phân quyền)

• Lồng URL quá sâu quá hai cấp

• Lưu token trong localStorage (tạo lỗ hổng XSS)

• Bỏ qua idempotency cho yêu cầu POST

• Trả về thông điệp lỗi chung chung không có chi tiết khả dụng

Kết luận

Tôi hiểu rằng học thuộc định nghĩa sẽ không đảm bảo bạn vượt qua mọi buổi phỏng vấn kỹ thuật. Thực tế là kỹ thuật ngoài đời thường đòi hỏi phá vỡ các "quy tắc" nghiêm ngặt vừa bàn, và nhà tuyển dụng quan tâm đến lập luận của bạn hơn là khả năng đọc vanh vách đặc tả RFC. Với các vai trò chuyên sâu, kiến thức lĩnh vực hoặc chuyên môn framework cụ thể có thể vẫn là yếu tố quyết định.

Nhưng nắm vững các nền tảng REST vẫn quan trọng dù bạn không gặp đúng các câu hỏi này. Nó là bản thiết kế để hiểu cách web hiện đại vận hành. Khi bạn được yêu cầu thiết kế hệ thống mới hoặc debug sự cố production, hiểu sự khác biệt giữa 401 và 403 (như tôi đã giải thích) giúp bạn giải quyết vấn đề nhanh hơn. Bạn sẽ nhận ra vì sao chuẩn hóa tương tác API, không chỉ viết mã chạy được, là dấu ấn của kỹ sư cấp cao.

Nếu bạn muốn đào sâu vào xây dựng các hệ thống này, hãy xem khóa học Giới thiệu về API trong Python của chúng tôi.