City 311 wants Data API builder to expose request entities so mobile clients can page results and filter by status. Which DAB configuration focus is correct?
Select an answer to reveal the explanation.
Short Explanation
311 apps need bite-sized pages and status filters—not a firehose of every request ever filed. Turn those on in the DAB entity config.
Full Explanation
City 311 wants Data API builder to expose request entities so mobile clients can page results and filter by status. The correct DAB configuration focus is to configure those request entities with pagination and filtering enabled for REST or GraphQL clients. Pagination keeps response sizes manageable for field workers; status filters let queues show open, closed, or assigned 311 requests without downloading the entire history. That entity-level API design is core to DP-800 Azure integration skills for SQL-backed municipal APIs.
Exposing unbounded result sets with no pagination or filter options fails scalability and client usability—mobile apps can choke on full historical dumps. Disabling entity access and requiring raw SQL from every mobile client fails security and architecture: phones should not become ad-hoc SQL consoles against 311 databases. Removing status columns from the API so clients cannot filter work queues fails the stated product need and pushes filtering into inefficient client-side scans.
Exam caveat: DAB entity configuration questions that mention paging and filtering expect those features enabled on the entity—not unbounded dumps or raw SQL. Options that remove filterable fields contradict the stem.
Operational check: enable pagination and filtering on the 311 request entity in DAB, call the REST or GraphQL endpoint with a page size and status filter, and verify only matching rows return in bounded pages. Load-test a pathological unfiltered client path if misconfigured, and confirm configuration review prevents shipping unbounded defaults to production mobile builds.