Login

Phỏng vấn REST API: phương thức HTTP, mã trạng thái và thiết kế endpoint

  • author-image

    Nguyễn Đình Cường

  • blog-tag
  • blog-comment 0 comment
  • created-date 09 Nov, 2026
blog-thumbnail

API là cầu nối giữa giao diện và máy chủ, nên câu hỏi về REST xuất hiện ở hầu hết vị trí backend và fullstack. Người phỏng vấn muốn biết bạn có thiết kế endpoint rõ ràng, dùng đúng phương thức và mã trạng thái, và nghĩ đến bảo mật hay không.

REST là gì?

REST là phong cách kiến trúc để thiết kế dịch vụ web xoay quanh tài nguyên, mỗi tài nguyên có một địa chỉ (URL) và được thao tác bằng các phương thức HTTP chuẩn. Các nguyên tắc thường được nhắc là: máy khách và máy chủ tách biệt, không lưu trạng thái giữa các request (stateless), có thể cache, và giao diện thống nhất.

Phương thức HTTP và ý nghĩa

Phương thứcMục đíchIdempotent
GETLấy tài nguyênCó
POSTTạo mới hoặc thực hiện hành độngKhông
PUTThay thế toàn bộ tài nguyênCó
PATCHCập nhật một phầnThường không bảo đảm
DELETEXóa tài nguyênCó

Idempotent nghĩa là gọi một lần hay nhiều lần cho cùng một kết quả trạng thái. Điều này quan trọng khi mạng lỗi và client phải thử lại.

Mã trạng thái cần nhớ

  • 200 OK: thành công. 201 Created: tạo mới thành công. 204 No Content: thành công không có nội dung.
  • 400 Bad Request: yêu cầu sai cú pháp. 422: dữ liệu không hợp lệ về nghiệp vụ.
  • 401 Unauthorized: chưa xác thực. 403 Forbidden: đã xác thực nhưng không đủ quyền.
  • 404 Not Found: không tìm thấy. 409 Conflict: xung đột trạng thái. 429: gọi quá nhiều.
  • 500: lỗi máy chủ. 503: dịch vụ tạm thời không sẵn sàng.

Thiết kế endpoint

Dùng danh từ số nhiều cho tài nguyên, để phương thức HTTP biểu thị hành động:

GET    /api/posts            danh sách bài viếtPOST   /api/posts            tạo bài viếtGET    /api/posts/42         chi tiết bài viếtPATCH  /api/posts/42         cập nhật một phầnDELETE /api/posts/42         xóaGET    /api/posts/42/comments  bình luận của bài viết

Tránh các đường dẫn kiểu /getPost hoặc /deletePost vì động từ đã nằm ở phương thức HTTP.

Phản hồi lỗi nhất quán

{  "error": {    "code": "VALIDATION_FAILED",    "message": "Email không hợp lệ",    "fields": { "email": ["Định dạng không đúng"] }  }}

Phân trang, lọc, sắp xếp

Danh sách lớn cần phân trang để tránh trả về quá nhiều dữ liệu. Có hai cách thường gặp: theo trang (?page=2&per_page=20) đơn giản dễ dùng, và theo con trỏ (cursor) ổn định hơn với dữ liệu thay đổi liên tục. Lọc và sắp xếp qua tham số truy vấn như ?status=active&sort=-created_at.

Xác thực và phân quyền

  • Session/cookie: quen thuộc với ứng dụng web truyền thống.
  • Token như JWT: máy chủ ký token, client gửi kèm header Authorization: Bearer ...; không lưu trạng thái nhưng khó thu hồi sớm nếu không có cơ chế bổ sung.
  • OAuth 2.0: ủy quyền cho bên thứ ba truy cập dữ liệu mà không chia sẻ mật khẩu.

Luôn dùng HTTPS, kiểm tra quyền ở phía máy chủ cho từng tài nguyên, và không tin dữ liệu từ client.

Phiên bản hóa và tài liệu

Khi API thay đổi theo cách không tương thích, dùng phiên bản như /api/v1/ để không phá ứng dụng cũ. Tài liệu hóa bằng OpenAPI/Swagger giúp người dùng API và nhóm kiểm thử nắm hợp đồng chính xác.

Những câu hỏi ngắn hay đi kèm

  • PUT và PATCH khác nhau thế nào? PUT thay thế toàn bộ tài nguyên bằng dữ liệu gửi lên, PATCH chỉ sửa các trường được gửi.
  • CORS là gì? Cơ chế của trình duyệt kiểm soát việc trang ở một nguồn gọi API ở nguồn khác; máy chủ phải trả về các header cho phép phù hợp.
  • Stateless nghĩa là gì? Mỗi request tự mang đủ thông tin để máy chủ xử lý, máy chủ không phải nhớ client giữa các lần gọi, nên dễ mở rộng ngang.
  • Làm sao ngăn gọi API quá nhiều? Dùng giới hạn tần suất (rate limiting) theo người dùng hoặc địa chỉ IP và trả mã 429 kèm thời gian chờ.
  • REST và GraphQL khác gì? REST có nhiều endpoint theo tài nguyên, GraphQL thường có một endpoint và client chọn đúng trường cần lấy; mỗi loại có ưu nhược điểm riêng.

Cách đóng gói câu trả lời

Với câu hỏi thiết kế như "thiết kế API cho ứng dụng đặt phòng", hãy bắt đầu bằng tài nguyên chính, liệt kê endpoint, nói về xác thực và phân quyền, rồi mới đến phân trang, lỗi và phiên bản hóa. Đi theo thứ tự đó giúp câu trả lời có cấu trúc và không bị sót ý.

Kết luận

Để gây ấn tượng, hãy chuẩn bị một API bạn tự thiết kế, nêu rõ vì sao chọn mã trạng thái, cách xác thực và xử lý lỗi. Một câu chuyện cụ thể luôn thuyết phục hơn danh sách định nghĩa.

Bạn có thể luyện thiết kế và xây dựng API qua các khóa backend tại codebem.com.

author_photo
Nguyễn Đình Cường

0 comment