# Các câu hỏi trắc nghiệm về API design (đề 2)

### Q1

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

~~### Q2

~~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~~
### Q3

Mục đích chính của việc tổ chức APIs bằng cách sử dụng tags là gì?
> 3 đáp án cuối nó không khớp với câu hỏi luôn ạ, nó là cách tổ chức chứ không phải mục đích
> [name=Thanh Nguyễn Thạc Đan]
- [x] Dễ dàng quản lý và tìm kiếm API theo nhóm
- [ ] Tăng tính ngẫu nhiên trong việc tổ chức API
- [ ] Liên kết API với cấu trúc dữ liệu cụ thể
- [ ] Tạo điều kiện cho việc sắp xếp API theo thời gian
### Q4

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
### Q5

Khi nào bạn nên sử dụng các tài liệu phụ trợ cho API?
> [name=Thanh Nguyễn Thạc Đan] 2 đáp án cuối cũng không sai, nên cảm giác chưa chặt chẽ lắm
- [x] Khi cần cung cấp hướng dẫn chi tiết và bổ sung về cách sử dụng API
- [ ] Khi muốn tăng độ phức tạp của tài liệu API
- [ ] Khi cần làm mờ đi các điểm quan trọng của API
- [x] Khi cần giải thích thêm các ví dụ không nằm trong tài liệu chính
### Q6

Phát biểu nào dưới đây là **ĐÚNG** khi nói về **common model** được định nghĩa trong thư mục gốc `common`?
- [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 đị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ẻ.
### Q7

Đâu là cách làm **ĐÚNG** khi định nghĩa `pagination` của Response khi thiết kế API?

- [ ] Sử dụng model `pagination` được định nghĩa trong service hiện tại
- [ ] Sự dụng model `pagination` trong thư mục con `common` của Layer tương ứng
- [ ] Sử dụng model `pagination` trong bất kì thư mục `common`
- [x] Sử dụng model `paginationOffsetResponse` hoặc `paginationResponse` trong thư mục gốc `common`

### Q8

Đối với một API trả về danh sách objects, khi nào nên chọn `pagination` với `offset` (keyset pagination) thay vì trả ra `page`, `pageSize`, `totalItems`?

- [x] Khi cần yêu cầu về performance của API
- [ ] Luôn ưu tiên dùng keyset pagination
- [ ] Khi xác định được primary key của object để định nghĩa giá trị offset
- [ ] Dùng loại nào cũng được
### Q9

Yêu cầu nào dưới đây nằm trong checklist của một MR trên repo API Documentation?

- [x] Gắn thẻ Tag cho tất cả các API
- [ ] Tất cả các comment thread cần được giải quyết
- [x] Các API có cùng Tag cần được đặt cạnh nhau trong file
- [ ] Điền đầy đủ thông tin theo template của MR
- [x] Chỉ rõ link UI confluence trong phần mô tả của các BFF API

### Q10

Ví dụ về yêu cầu UX như sau: Màn hình cho phép admin lựa chọn **paymentCardEncodeFormat: E1, E2** cho từng đơn vị bán. Mặc định khi không lựa chọn nghĩa là đơn vị bán đó không sử dụng thẻ để thanh toán.
Đâu sẽ là lựa chọn tốt nhất khi design data này cho API **upsertRetailer** trong **Core Service**?

- [ ] **A.** paymentCardEncodeFormat: Enum "E1", "E2", "None"
- [ ] **B.** paymentCardEncodeFormat: Enum "E1", "E2". (giá trị Null khi không sử dụng thẻ thanh toán)
- [x] **C.** isUsingPaymentCard: bool; paymentCardEncodeFormat: Enum "E1", "E2"
- [ ] **D.** Cả hai đáp án A và B đều đúng
### Q11

Giữa đối tượng **campaign** và **promotion** có mối quan hệ N-N, hiện tại Core Service đã tồn tại Tag `campaign` và`promotion`. Nếu cần định nghĩa một API mới Lấy danh sách promotion của campaign, API này nên có Tag là gì?
- [ ] `campaign`
- [x] `promotion`
- [ ] Tạo Tag mới `campaign-promotion`
- [ ] Tạo Tag mới `campaign-promotion` trong trường hợp cũng cần có API Lấy danh sách campaign sử dụng promotion, ngược lại thì sử dụng Tag `campaign`
### Q12

Trong trường hợp nào cần tạo API mới mà không sử dụng lại API có sẵn đối với **Presentation Layer**?

- [ ] Cùng Reference Object, cùng mục đích sử dụng nhưng được dùng trong màn hình khác nhau
- [ ] Cùng mục đích sử dụng nhưng cần bổ sung thêm request param
- [x] Khác phương thức xác thực
- [ ] Cùng mục đích sử dụng nhưng cần bổ sung thêm field trong cả request và response
### Q13

Phát biểu nào là **ĐÚNG** khi nói về **Presentation Layer**?
- [x] Nhóm các API theo màn hình
- [x] Có thể refer tới Reference Object của Core Service (nhưng nên hạn chế)
- [ ] Có thể refer tới Reference Object của BFF khác
- [ ] Nhóm các API CRUD object vào cùng Tag
- [x] Không để chung API **public** với API **non-public** trong cùng folder
### Q14

Vì sao nên tạo Reference Object khi object đó phải đủ lớn và được sử dụng ở nhiều nơi?

- [x] Khi tạo Reference Object nhỏ lẻ, service sẽ có rất nhiều Reference Object, khó kiểm soát và gây khó khăn trong việc thiết kế API
- [x] Không nên tạo Reference Object nếu chỉ dùng ở một nơi vì sẽ khó review API design
- [x] Cần tạo Reference Object khi được dùng ở nhiều nơi để dễ kiểm soát thay đổi của Object, tránh thiếu sót khi phải cập nhật ở nhiều nơi
- [ ] Làm trang apidoc.teko.vn load chậm

### Q15

Vì sao khi thiết kế API cho **Core Logic Layer** cần dựa trên Response Data, và tổ chức API theo Business Data Object?

- [x] API của Core Service cần quan tâm tới dữ liệu mong muốn trả ra là gì, không cần quan tâm tới nghiệp vụ dùng như thế nào
- [ ] Các API cùng chung Business Data Object thường có cùng mục đích nên cần được gom cùng nhau
- [x] Gom nhóm API theo Business Data Object để dễ dàng trong việc thiết kế API, quyết định thêm mới hoặc cập nhật API, mỗi Data Object chỉ nên có một bộ CRUD API
- [x] Vì Business Data Object là đối tượng chính của API Core, tổ chức API theo Business Data Object giúp dễ dàng tra cứu API cần sử dụng
### Q16

Bạn cần thiết kế một API để lấy danh sách các sản phẩm kèm theo chi tiết của từng sản phẩm. Số lượng sản phẩm lớn và chi tiết sản phẩm nằm trên cùng một bảng dữ liệu. Bạn sẽ thiết kế ***Core API*** như thế nào?

> [name=Thanh Nguyễn Thạc Đan] Chưa có đáp án, với câu hỏi Core API, mình đổi đề bài một chút, chỉ đề cập tới việc số lượng sản phẩm nhiều, chi tiết sản phẩm nằm trên cùng một bảng dữ liệu, còn hiển thị phân trang thì đề cập trong API BFF thôi ạ

- [ ] GET /products (support pagination, return [productDetail])
- [x] GET /products (support pagination, return [productBaseInfo]); GET /products/{productId} (return productDetail)
- [ ] GET /products (return [productBaseInfo]); GET /productDetails (filter productIds, return [productDetail])
- [ ] GET /products (return [productBaseInfo]); GET /products/{productId} (return productDetail)
### Q17

Bạn cần thiết kế một API để lấy danh sách các sản phẩm kèm theo chi tiết của từng sản phẩm. Yêu cầu này bao gồm việc phân trang kết quả trả về. Bạn sẽ thiết kế ***BFF API*** như thế nào?

- [x] GET /bff/products (support pagination, return [productDetail])
- [ ] GET /bff/products (return [productBaseInfo])
- [ ] GET /bff/products (filter productId, return [productDetail])
- [ ] GET /bff/products/{productId} (return [productDetail])

### Q18

Nên làm gì các điều nào sau đây để giúp giảm thời gian **review** MR API?

- [ ] Viết mô tả MR sơ sài cho nhanh, giảm thời gian tạo MR.
- [x] Chủ động nhắn tin trực tiếp, đặt cuộc họp nhanh để trao đổi với Techinal design committee và các team/PIC liên quan để resolve nhanh các thread dài/phức tạp trong MR.
- [ ] Bỏ qua, không cần viết mô tả của các trường, API mọi người review cho nhanh vì nội dung ít.
- [x] Cố gắng cung cấp đầy đủ thông tin trong MR để người review không mất công tìm kiếm, hỏi lại người tạo MR.

### Q19

Màn hình filter danh sách sản phẩm (có phân trang) có các điều kiện filter và một nút search, một nút export excel, các chức năng này về sau không phát sinh điều kiện filter khác nhau. Đâu là cách thiết kế api BFF đúng:

- [ ] BFF api chỉ cần một api search sản phẩm, trong đó có field isExport = true
- [ ] BFF api chỉ cần một api search sản phẩm, trong đó có field exportType = ["pdf"]
- [ ] BFF api cần 2 api để phục vụ phân quyền, 1 api search sản phẩm, 1 api export sản phẩm giống filter search
- [x] BFF api cần 2 api để phục vụ phân quyền, 1 api search sản phẩm, 1 api export sản phẩm giống filter search nhưng bỏ các tham số paging.

### Q20

Một MR submit api doc mới bên BFF cần:

- [x] Mô tả description MR rõ ràng
- [x] Đính kèm link confluence vào tên api doc
- [ ] Gắn tag API document
- [x] Gắn api change [BFF][GET] /api/v1/bff-api