Product teams expose GraphQL and REST APIs whose field names never link back to glossary business terms. What metadata practice should close that gap?
Select an answer to reveal the explanation.
Short Explanation
APIs are storefront windows—if the labels do not match the glossary, shoppers buy the wrong thing. Treat API schemas as metadata and link fields to official business terms. CamelCase guesses are not a glossary.
Full Explanation
APIs are data contracts and should be managed as metadata assets linked to official business terms. When GraphQL and REST field names never link back to the glossary, consumers infer meaning from camelCase and recreate semantic drift at the edge. Treating APIs as undocumented implementation details forever blocks safe reuse across civic applications. Documenting only database tables while forbidding API contract metadata ignores how modern consumers actually integrate. Assuming camelCase reveals business meaning is wishful thinking. Exam answers extend metadata scope to API schemas and contracts. Caveat: API metadata must version with breaking changes and expose deprecation the same way tables do. Operationally, register priority public and partner APIs in the catalog, map fields to glossary terms, publish ownership and change notes, and require new endpoints to complete that linkage before production promotion. Gate API production promotion on catalog linkage: no glossary term mapping, no go-live for citizen-facing or partner-facing contracts. Breaking API changes should trigger the same deprecation metadata patterns used for tables—successor fields, dates, and consumer notices tied to glossary terms.