API / SERVICE DATA MODELLING — Learn free

Self-check

Questions 1–10 of 10

1. What does API / Service Data Modelling concentrate on?
Question 1A. How data is exposed, requested and consumed across interfacesB. How data is physically stored in tablesC. How data is partitioned across cluster nodesD. How data is normalised to remove redundancyE. How events are replayed to rebuild state
2. In API / Service Data Modelling, what role does a well-designed API model play between systems?
Question 2A. A caching layerB. A formal contract between service providers and service consumersC. A replacement for the database schemaD. A physical indexE. An event log
3. Which standards are named for expressing API data models?
Question 3A. SQL DDL, ERD and UMLB. JSON Schema, XSD and DTDC. OpenAPI (Swagger) for REST, GraphQL schemas and WSDL for SOAPD. OWL, RDF and SPARQLE. Avro, Parquet and ORC
4. In the loan approval API ecosystem, which endpoint do regulatory authorities consume for compliance monitoring?
Question 4A. /loanApplicationsB. /loanApprovalsC. /loanOfficersD. /loanReportsE. /customers
5. What happens to the API schema if a bank's internal storage shifts from relational databases to NoSQL or event-driven architectures?
Question 5A. It must be rewritten for every consumerB. It becomes a GraphQL schema automaticallyC. It is replaced by direct database accessD. It is versioned as a new major releaseE. It remains stable, ensuring consistent communication across stakeholders
6. What advantage does the GraphQL loan example illustrate?
Question 6A. A consumer can request only specific fields such as LoanAmount, Status and the related names, avoiding unnecessary data transferB. A consumer receives every field of every related entity in one callC. A consumer can update the database schema directlyD. A consumer can bypass the API contractE. A consumer can submit XML instead of JSON
7. Which fields does the REST request to POST /loanApplications contain in the loan approval example?
Question 7A. LoanID, Status and InterestRateB. CustomerID, LoanAmount and OfficerIDC. LoanID, ApprovalStatus and TermD. OfficerID, Branch and RegionE. CustomerID, Name and CreditScore
8. Which of the following is NOT listed as a challenge of API / Service Data Modelling?
Question 8A. Over-fetching or under-fetching of data in REST APIsB. Versioning and backward compatibility requiring careful governanceC. Inability to represent nested objectsD. Exposing too much internal detailE. Providing insufficient context for consumers
9. Why do normalisation forms not apply to API modelling?
Question 9A. Because APIs store data in 6NF by defaultB. Because APIs use only flat structuresC. Because APIs cannot carry keysD. Because the focus is message exchange, where canonical representations matter more than normalised schemasE. Because APIs are always backed by NoSQL
10. How does Object-Oriented Data Modelling differ from API / Service Data Modelling, given that both represent entities as rich nested objects?
Question 10A. APIs store methods with the data while OODM does notB. OODM uses JSON while APIs use binary formatsC. APIs are older than OODMD. OODM is used only for regulatorsE. OODM bundled logic with data inside the database, whereas APIs keep only the data representation and leave logic in application code or services