API Design Quiz

# API Design Quiz ### Q1 Which of the following statements are **TRUE** when talking about common Reference Objects, defined in the **root** `common` folder? - [x] They are intended to be used by all services. - [ ] They are intended to be used by several services. - [ ] They are defined in the `common.yaml` file. - [x] Each object model should be defined in its own `yaml` file. ### Q2 Which is the correct way to define the **pagination** in response? - [ ] Use the **pagination** model defined in the current service - [ ] Use the **pagination** model in the sub `common` folder of the current layer - [ ] Use the **pagination** model in any `common` folder - [x] Use either **paginationOffsetResponse** or **paginationResponse** located in the root `common` folder ### Q3 For an API that returns a list of objects, when should you choose pagination with **offset** (keyset pagination) instead of returning **page**, **pageSize**, **totalItems**? - [x] When there is a need for API performance optimization - [ ] Always prefer to use keyset pagination - [ ] When the primary key of the object is determined to define the offset value - [ ] The choice does not make a difference ### Q4 Which of the following are defined in the root `common` folder? - [x] **page**, **pageSize** in query - [ ] **page**, **pageSize** in request body - [x] **Authorization** in header for authenticating via IAM - [x] **baseApiResponse** object - [ ] **platformId** ### Q5 What is the correct value for the `code` field in a successful API response? - [ ] "200" - [ ] 0 - [x] 200 - [ ] Depends on each service - [ ] "00" ### Q6 When should you mark fields/APIs as deprecated? - [ ] **A.** When fields/APIs are not used anywhere - [ ] **B.** When APIs are not used anywhere, and when fields are not used in new features but are still used in old features - [x] **C.** When fields/APIs are not used in new features but still required for backward compatibility - [ ] **D.** Both A and C are correct ### Q7 Which items are included in an API Docs MR checklist? - [x] Set tags for all APIs - [ ] Ensure that all comment threads are resolved - [x] Place all API endpoints together by Tag in a file - [ ] Fill out the MR template completely - [x] Specify UI confluence links in the Description of BFF APIs ### Q8 Who is responsible for clicking **Resolve thread** in the comment threads of an MR? - [ ] The owner of the MR - [ ] The person who will approve the MR - [ ] The person who was assigned to the MR - [ ] The person who will merge the MR - [x] The person who created the comment thread ### Q9 Which changes should be labeled **API DESIGN** in MR? - [x] Fixing spelling errors in field names - [x] Changing API path - [x] Grouping common objects into a Reference Object without changing the API - [x] Add values to an Enum field - [x] Marking a field as `required` - [ ] Adding error codes ### Q10 Which types of change should be labeled as **API DOCUMENT**? - [x] Add Error responses - [x] Add validation specification for API fields - [ ] Move a Reference Object to a separated file - [ ] Add new Error in **baseApiErrors** in root `common` folder - [x] Add tags for APIs ### Q11 When should we create a **Reference Object**? - [ ] Each API response object should be a Reference Object - [ ] When the Reference Object is coressponding to a DB entity - [ ] When it can be reused in at least 2 places - [x] When it can be reused in a large number of places (can be defined as a `common` object) - [x] When the Reference Object is big and can be reused in at least 2 places ### Q12 Which statement is CORRECT regarding the API of the **Core Logic Layer**? - [x] It should not have authorization and language selection logic - [ ] It can refer to the Reference Objects of another Core Service - [x] It is not allowed to refer to the Reference Object of the Presentation Layer - [x] CRUD APIs of the same Business Data Object must be tagged together - [x] APIs are organized and managed according to the Business Data Object ### Q13 ~~Which component will we base on to decide to create or update a Core API?~~ - [ ] The purpose of the API - [ ] Request params - [x] Response data - [ ] Code flow of the API implementation ### Q14 In which of the following cases should we choose to update an existing Core API instead of create a new one? - [x] Same Reference Object in response data, but different usage scenarios - [x] Same Reference Object in response data, additional fields in response - [x] Same Reference Object in response data, but additional fields in request and response - [ ] New Reference Object in response data ### Q15 UX requirement example: Allow admin to select **paymentCardEncodeFormat: E1, E2** for each retailer. Default not being selected means that the retailer does not use cards for payment. Which is the best solution when designing fields for API **upsertRetailer** in **Core Service**? - [ ] **A.** paymentCardEncodeFormat: Enum "E1", "E2", "None" - [ ] **B.** paymentCardEncodeFormat: E1, E2. (Null value for not using cards for payment) - [x] **C.** isUsingPaymentCard: bool; paymentCardEncodeFormat: E1, E2 - [ ] **D.** Both A and B are correct ### Q16 There is a N-N relation between **campaign** and **promotion** objects, we already have tag `campaign` and tag `promotion` in Core Service. If you define a new Core API to get list promotions of the campaign. Which tag is for API? - [ ] `campaign` - [x] `promotion` - [ ] Create a new mapping tag `campaign-promotion` - [ ] Create a new mapping tag `campaign-promotion` if have another API Get list campaigns using the promotion, otherwise set tag `campaign` ### Q17 An example of a UX requirement is as follows: Display a list of merchants (with the ability to search by **merchantId**) returning basic information, and a screen showing detailed information about a merchant along with a list of terminals belonging to that merchant. ***Assuming that the details of the merchant do not have excessive information*** How should the **Core API** be designed? - [ ] **`GET /merchants`** (filter `merchantId`, return `[merchantBaseInfo]`); **`GET /merchants/{merchantId}`** (return `merchantDetailWithTerminals`) - [ ] **`GET /merchants`** (filter `merchantIds`, return `[merchantBaseInfo]`); **`GET /merchants/{merchantId}`** (return `merchantDetail`); **`GET /terminals`** (filter `merchantId`, return `[terminalDetail]`) - [ ] **`GET /merchants`** (filter `merchantId`, return `[merchantBaseInfo]`); **`GET /merchants/{merchantId}`** (return `merchantDetail`); **`GET /terminals`** (filter `merchantId`, return `[terminalDetail]`) - [x] **`GET /merchants`** (filter `merchantIds`, return `[merchantDetail]`); **`GET /terminals`** (filter `merchantId`, return `[terminalDetail]`) ### Q18 Which of the following cases will we create a new API for the **Presentation Layer**? - [ ] Same response data, same intended use but in the different screen - [ ] Same intended use but additional request params - [x] Different permission - [ ] Same intended use but additional request & response fields ### Q19 Which statements are **TRUE** for the **Presentation Layer**? - [x] Group APIs by Screen - [ ] Can ref Reference Object from Core Service - [ ] Can ref Reference Object from another Presentation Layer - [ ] Group all CRUD APIs on the same Tags - [x] Do not mix **public** API with **non-public** API in the same folder ### Q20 UX requirement example: Allow admin to select **paymentCardEncodeFormat: E1, E2** for each retailer. Default not being selected means that the retailer does not use cards for payment. Which is the best solution when designing fields for API **upsertRetailer** in **BFF**? - [ ] **A.** paymentCardEncodeFormat: E1, E2, None - [x] **B.** paymentCardEncodeFormat: E1, E2. (Null value for not using cards for payment) - [ ] **C.** isUsingPaymentCard: bool; paymentCardEncodeFormat: E1, E2 - [ ] **D.** Both A and B are correct ### Q22 UX requirement example: Show list merchants (can search by **merchantName**, **merchantId**) with basic info; and show full detail of a merchant along with list terminals info. Assume that: full **merchant** object does not have too much infos. How will we design for the **BFF APIs**? - [x] **`GET /api/merchants`** (filter merchantName, merchantId, return `[merchantBaseInfo]`); **`GET /api/merchants/{merchantId}`** (return `merchantDetailWithTerminals`) - [ ] **`GET /api/merchants`** (filter merchantName, merchantIds, return `[merchantBaseInfo]`); **`GET /api/merchants/{merchantId}`** (return `merchantDetail`); **`GET /api/terminals`** (filter merchantId, return `[terminalDetail]`) - [ ] **`GET /api/merchants`** (filter merchantName, merchantId, return `[merchantBaseInfo]`); **`GET /api/merchants/{merchantId}`** (return `merchantDetail`); **`GET /api/terminals`** (filter merchantId, return `[terminalDetail]`) - [ ] **`GET /api/merchants`** (filter merchantName, merchantIds, return `[merchantDetail]`); **`GET /api/terminals`** (filter merchantId, return `[terminalDetail]`) ### Q23 In which of the following cases should we create an `updateObjectStatus` API in **Core Service** instead of combining in `upsertObject` API? - [ ] There should be only 1`upsertObject` API for all cases - [ ] When `objectStatus` is always updated individually, do not update with any other information of the object - [ ] When we have complicated changing status flows for the object - [x] When we have complicated changing status flows for the object and `objectStatus` is always updated individually without other object infos ### Q24 How should we combine or seperate APIs? - [ ] Should combine APIs to easy maintain - [x] Combine BFF APIs by screen and seperate BFF APIs by user action - [x] Combine or seperate Core APIs by Reference Object - [ ] Seperate BFF APIs by action and seperate Core APIs by function ### Q25 Why is it necessary to design APIs for the Core Logic Layer based on Response Data and organize APIs according to Business Data Objects? - [x] APIs of Core Services need to focus on what desired data to return, without concerning how the business will use it. - [ ] APIs sharing the same Business Data Object usually have the same purpose so should be grouped together. - [x] Grouping APIs by Business Data Objects makes it easier to design APIs, make decisions on adding or updating APIs, and each Data Object should have only one set of CRUD APIs. - [x] Since Business Data Object is the main entity of Core APIs, organizing APIs according to Business Data Objects helps in easy retrieval of required APIs.