Các câu hỏi trắc nghiệm về API design

### Q1

Phát biểu nào dưới đây về common model được định nghĩa trong thư mục gốc `common` là **ĐÚNG**?
- [x] Được thiết kế để có thể sử dụng cho tất cả các service
- [ ] Được thiết kế để có thể sử dụng cho một vài service được chọn
- [ ] Được định nghĩa trong file `common.yaml`.
- [x] Mỗi model nên được định nghĩa trong từng file `yaml` riêng lẻ.

### Q2

Cấu trúc thư mục nào được khuyến nghị để tổ chức các file API?
- [ ] Được tổ chức bằng các tên ngẫu nhiên
- [x] Những service con nội bộ trong cùng một project được đặt trong cùng thư mục
- [ ] Được tổ chức theo chức năng của API
- [x] Được tổ chức theo Layer, công ty

### Q3

Khi nào bạn nên sử dụng `int64` làm kiểu dữ liệu cho field?
- [x] Khi field yêu cầu kích thước số nguyên lớn hơn
- [ ] Khi field cần nhỏ hơn để cải thiện hiệu suất
- [ ] Khi chuyển đổi số thành chuỗi cho xử lý frontend
- [ ] Khi API committee đề xuất

### Q4

Cách đặt tên giá trị enum nào là đúng?
- [x] Theo định dạng `UPPERCASE_UNDERSCORE` cho các thuật ngữ tiếng Anh
- [ ] Sử dụng bất kỳ định dạng nào mà không cần nhất quán
- [ ] Theo định dạng `lowercase-with-hyphen` cho các thuật ngữ không phải tiếng Anh
- [ ] Không có quy tắc đặt tên cụ thể

### Q5

Định dạng nào là đúng cho một field thời gian?
- [ ] Chuỗi không có định dạng cụ thể
- [x] Unix timestamp là số nguyên (định dạng int32)
- [ ] Đối tượng Date dưới dạng chuỗi
- [ ] Tùy thuộc vào chức năng của API

### Q6

Phương pháp nào được khuyến nghị để xử lý các yêu cầu API GET với nhiều tham số filter?
- [ ] Luôn sử dụng tham số query
- [x] Cân nhắc chuyển sang phương thức POST
- [ ] Tránh sử dụng các bộ lọc
- [ ] Sử dụng cả tham số query và path

### Q7

Mục đích của `baseApiResponse` trong thiết kế API là gì?
- [x] Chuẩn hóa các phản hồi thành công
- [ ] Định nghĩa các mô hình dữ liệu chung
- [ ] Chỉ xử lý các phản hồi lỗi
- [ ] Triển khai logic frontend

### Q8

Bạn cần xem xét điều gì khi định nghĩa Async API hoặc RAM event?
- [x] Ý nghĩa và mục đích của event
- [ ] Số lượng người tiêu dùng hiện tại
- [ ] Kích thước RAM được phân bổ
- [ ] Tần suất xuất bản event

### Q9

API nên được tổ chức như thế nào trong bối cảnh BFF (Backend for Frontend)?
- [x] Gom nhóm và đặt tên theo khách hàng, nhóm người dùng, màn hình
- [ ] Được tổ chức ngẫu nhiên
- [ ] Không có quy tắc đặt tên cụ thể
- [ ] Dựa trên cấu trúc cơ sở dữ liệu

### Q10

Khi nào bạn nên sử dụng `Sub-common object`?
- [ ] Luôn sử dụng cho mọi service
- [x] Sử dụng cho một vài service trong cùng một nhóm
- [ ] Chỉ cho Core APIs
- [ ] Cho mỗi API mới

### Q11

Nguyên tắc chính khi tạo Reference Objects là gì?
- [ ] Tạo chúng cho mỗi API mới
- [ ] Giới hạn sử dụng chúng cho một API cụ thể
- [x] Đảm bảo chúng được sử dụng trong nhiều API
- [ ] Thường xuyên refactor chúng

### Q12

Làm thế nào để bạn xử lý các thay đổi API trong một dự án lớn?
- [ ] Gộp tất cả các thay đổi vào một MR
- [x] Tách MR dựa trên các layer hoặc các service liên quan
- [ ] Bỏ qua các thay đổi
- [ ] Tạo nhiều MR nhỏ cho mỗi thay đổi API

### Q13

API paths được đặt theo format nào?

- [ ] `camelCase`
- [ ] `snake_case`
- [x] `kebab-case`
- [ ] Cả 3 đáp án trên

### Q14

Mục đích của việc định nghĩa các đối tượng `paginationRequest` và `paginationResponse` là gì?
- [ ] Xử lý các yêu cầu không đồng bộ
- [ ] Triển khai các tính năng UI frontend
- [ ] Lưu trữ dữ liệu phản hồi API
- [x] Chuẩn hóa phân trang giữa các API

### Q15

Tên field trong response API nên được định dạng như thế nào?
- [ ] `snake_case`
- [x] `camelCase`
- [ ] `kebab-case`
- [ ] `PascalCase`

### Q16

Khi nào bạn nên định nghĩa một `common object`?
- [x] Khi nó được chia sẻ giữa tất cả các service
- [ ] Khi nó là duy nhất cho một service cụ thể
- [ ] Khi nó chỉ được sử dụng cho BFF APIs
- [ ] Khi nó cần thiết cho một API mới

### Q17

Điều gì sau đây được cân nhắc trong quá trình thiết kế BFF API?
- [ ] Cấu trúc cơ sở dữ liệu backend
- [x] Khách hàng, nhóm người dùng, màn hình
- [ ] Framework được sử dụng ở Frontend
- [ ] Các mẫu thiết kế frontend

### Q18

Cần làm gì khi cập nhật các Reference Objects?
- [ ] Chỉ cập nhật một object tại một thời điểm
- [ ] Chỉ cần quan tâm đến API tham chiếu đến object đó mà task yêu cầu, không cần quan tâm các API khác cũng tham chiếu đến object đó vì không thuộc phạm vi của task
- [ ] Tạo các object mới cho mỗi cập nhật API
- [x] Đảm bảo tính tương thích trên tất cả các API tham chiếu đến object được cập nhật

### Q19

Các API trong một service Core được tổ chức theo tiêu chí nào?
- [ ] Được tổ chức ngẫu nhiên
- [ ] Dựa trên yêu cầu của khách hàng
- [ ] Được tổ chức theo màn hình
- [x] Gom nhóm theo các business data object

### Q20

Khi nào bạn nên sử dụng `offsetPagination` thay cho `paginationRequest`?
- [ ] Luôn sử dụng `offsetPagination` để API có performance tốt nhất
- [ ] Chỉ cho các yêu cầu POST
- [ ] Chỉ cho các tập dữ liệu lớn
- [x] Khi API yêu cầu cao về performance, không cần lấy tổng số bản ghi

### Q21

Các điều nào sau đây là đúng?
- [ ] Tên trường boolean được đặt theo định dạng `camelCase`, đảm bảo đúng ngữ pháp là được
- [x] Tên trường boolean bắt đầu với tiền tố là `is/has`
- [x] Tham số trong query param có đinh dạng `camelCase`
- [ ] Tham số trong query param có đinh dạng `snake_case`

### Q22

Đâu là quy tắc đặt tên cho các API async?
- [ ] Đặt tên giống với các API thông thường
- [ ] Sử dụng các quy tắc đặt tên ngẫu nhiên
- [x] Tiền tố với `(Async API - RAM)` hoặc `(RAM)`
- [ ] Không chỉ định bất kỳ tiền tố nào

### Q23

Mục đích chính của việc tổ chức APIs bằng cách sử dụng tags là gì?
- [x] Dễ dàng quản lý và tìm kiếm API theo nhóm
- [ ] Tổ chức ngẫu nhiên
- [ ] Tổ chức theo các bảng cơ sở dữ liệu
- [ ] Dựa vào ngày tạo API

### Q24

Bạn nên bao gồm những gì trong phần mô tả MR cho các thay đổi thiết kế API?
- [x] Liên kết thiết kế API, mô tả rõ vấn đề, danh sách các thay đổi
- [ ] Sử dụng nguyên văn mô tả trong Jira ticket
- [ ] Chỉ tên API
- [ ] Các thay đổi được thực hiện mà không có giải thích

### Q25

Làm thế nào để bạn tổ chức file API trong một service?
- [x] Một file `openapi.yaml` cho các API và một thư mục con `models`
- [ ] File riêng biệt cho mỗi API mà không có thư mục con
- [ ] Một file duy nhất cho tất cả các API và models
- [ ] Nhiều file không có cấu trúc cụ thể

### Q26

Bạn cần xem xét điều gì khi tạo enums?
- [ ] Các quy tắc đặt tên ngẫu nhiên
- [ ] Các định dạng khác nhau cho mỗi giá trị enum
- [x] Nhất quán và rõ ràng trong toàn bộ dự án
- [ ] Không có quy tắc cụ thể

### Q27

Làm thế nào để bạn xử lý các thay đổi không tương thích ngược trong API?
- [ ] Cập nhật API hiện tại mà không thay đổi phiên bản
- [x] Tạo phiên bản mới của API
- [ ] Gửi thông báo lỗi tới người dùng API
- [ ] Bỏ qua thay đổi

### Q28

Bạn nên làm gì khi thêm một trường mới vào request body của một API mà không làm ảnh hưởng đến các bên đang tích hợp API chưa có nhu cầu sử dụng trường mới?
- [x] Đảm bảo trường mới là tùy chọn để duy trì tính tương thích
- [ ] Thêm trường mới bắt buộc
- [ ] Loại bỏ các trường cũ để tránh trùng lặp
- [ ] Yêu cầu cập nhật tất cả các service để sử dụng trường mới ngay lập tức

### Q29

Cách tốt nhất để quản lý các lỗi phổ biến trong API là gì?
- [ ] Sử dụng các mã lỗi ngẫu nhiên
- [ ] Chỉ sử dụng mã lỗi HTTP
- [ ] Để mỗi service xác định mã lỗi của riêng mình
- [x] Định nghĩa các mã lỗi chung trong một tài liệu chung

### Q30

Bạn nên làm gì khi thay đổi một enum trong API?
- [x] Đảm bảo tất cả các giá trị cũ vẫn được hỗ trợ
- [ ] Xóa các giá trị cũ mà không thông báo
- [ ] Chỉ cập nhật tài liệu mà không thay đổi mã
- [ ] Tạo một phiên bản mới của enum mà không thay đổi mã

### Q31

Khi nào bạn nên sử dụng các tài liệu phụ trợ cho API?
- [x] Khi cần giải thích chi tiết về cách sử dụng API
- [ ] Chỉ khi API không rõ ràng
- [ ] Khi tài liệu chính không đủ
- [ ] Khi muốn thêm ví dụ sử dụng cụ thể

### Q32

Bạn cần xem xét điều gì khi sử dụng các tiêu chuẩn RESTful cho API?
- [x] Phù hợp với các quy tắc RESTful chuẩn
- [ ] Sử dụng bất kỳ phương pháp nào miễn là API hoạt động
- [ ] Ưu tiên phương pháp riêng của công ty
- [ ] Tập trung vào hiệu suất mà không quan tâm đến tiêu chuẩn

### Q33

Làm thế nào để bạn quản lý các thay đổi lớn trong cấu trúc API?
- [x] Lập kế hoạch và thực hiện trong nhiều giai đoạn
- [ ] Thay đổi tất cả cùng một lúc
- [ ] Chỉ thay đổi khi cần thiết
- [ ] Để dev tự quản lý

### Q34

Bạn nên làm gì khi một API không còn cần thiết?
- [x] Đánh dấu là deprecated và cung cấp thời gian thông báo trước khi xóa
- [ ] Xóa ngay lập tức
- [ ] Thông báo cho tất cả người dùng nhưng vẫn giữ nguyên API
- [ ] Di chuyển tất cả người dùng sang API mới mà không thông báo

### Q35

Mục đích của việc sử dụng các model chung (common models) là gì?
- [x] Tái sử dụng và duy trì dễ dàng hơn
- [ ] Tăng độ phức tạp của dự án
- [ ] Giảm hiệu suất của API
- [ ] Làm cho việc phát triển trở nên khó khăn hơn

### Q36

Khi nào bạn nên định nghĩa một `common object`?
- [ ] Khi nó là duy nhất cho một service
- [x] Khi nó được chia sẻ cho tất cả các service
- [ ] Khi chỉ được sử dụng cho API BFF
- [ ] Khi cần cho một API mới

### Q37

Bạn nên xử lý thế nào khi cập nhật Reference Objects?
- [x] Đảm bảo tính tương thích trên tất cả các tham chiếu API
- [ ] Chỉ cập nhật một tham chiếu API một lần
- [ ] Bỏ qua các tham chiếu API hiện tại
- [ ] Tạo đối tượng mới cho mỗi cập nhật API

### Q38

Bạn nên sử dụng MR riêng biệt cho thay đổi thiết kế API trong trường hợp nào?
- [x] Đối với mỗi layer hoặc nhóm service liên quan
- [ ] Kết hợp tất cả các thay đổi vào một MR
- [ ] Bỏ qua việc cần MR riêng biệt
- [ ] Sử dụng MR riêng biệt chỉ cho các thay đổi nhỏ

### Q39

Theo API design guideline, các câu nào sau đây là **đúng** khi thiết kế các trường cho API?

- [ ] Đặt tên ngắn ngọn, chung chung
- [x] Cần định nghĩa số lượng tối đa với các trường dạng mảng
- [x] Các trường có type là number cần định nghĩa format cụ thể (float/double)
- [ ] Format mặc định của type integer là int64

### Q40

Các câu nào là **đúng** trong quá trình tạo MR API docs?

- [x] Yêu cầu bắt buộc có gắn link tài liệu API Design trên confluence với MR Design cho Epic
- [ ] Tick hết các checklist trong mô tả MR mà không cần biết đã thực hiện chưa để review cho nhanh
- [x] Yêu cầu TechPIC/L3/L4 review nội bộ (tối thiểu 1 approved) trước khi mark Ready để Committee review. Khi MR có thay đổi theo đề xuất của Committe cũng cần review nội bộ trước
- [x] Fix merged MR: là MR fix lỗi/bổ sung thiếu sót cho merged MR trước đó, mention link MR đã merged trước đó

### Q41

Chọn các câu **đúng** trong các câu sau khi nói về phần mô tả của các trường trong API?

- [ ] Chỉ cần mô tả chung chung hoặc dùng luôn tên trường làm mô tả, cho dù ý nghĩa trường đó phức tạp do mô tả nhiều thì mất công làm API, để thời gian đó code luôn khoẻ
- [x] Mô tả đầy đủ giúp người đọc (dev sử dụng API, dev cài đặt API) hiểu được ý nghĩa của trường, không mất thời gian hỏi lại người tạo API
- [x] Với các trường có ý nghĩa phức tạp, mô tả dài có thể gắn kèm link tài liệu mô tả chi tiết về trường đó
- [x] Với các trường có tên quá rõ ràng thì có thể không cần thêm mô tả