Permits applicants need fee quotes through an API, but the bureau does not want clients writing ad-hoc SQL against fee tables. How should they expose the logic via Data API builder?
Select an answer to reveal the explanation.
Short Explanation
Fee quotes belong behind a stored-proc “service window” in DAB—not an open buffet of fee tables for every client to poke with ad-hoc SQL.
Full Explanation
Permits applicants need fee quotes through an API, but the bureau does not want clients writing ad-hoc SQL against fee tables. They should expose a stored procedure through Data API builder that returns fee quotes instead of allowing ad-hoc SQL against fee tables. DAB can surface stored procedures as invokable operations, encapsulating municipal fee logic—rate schedules, waivers, calculation rules—behind a curated contract. Clients call the procedure endpoint; they do not receive broad table rights or invent SELECT/UPDATE statements against payment structures.
Granting clients unrestricted SELECT and UPDATE on all fee and payment tables fails least privilege and lets applicants (or compromised apps) read and mutate financial structures directly. Publishing database admin credentials inside the public permits mobile app fails catastrophically on secret handling and privilege. Requiring applicants to email a spreadsheet of fees with no API contract fails the API requirement and removes consistency/validation.
Exam caveat: when stems forbid ad-hoc SQL but still need API access to logic, expose stored procedures (or similarly curated operations) via DAB rather than raw tables. Admin credentials in mobile apps and wide table grants are hard-wrong.
Operational check: publish the fee-quote stored procedure through DAB, call it from a test permits client with sample inputs, verify quoted fees match bureau rules, and confirm fee/payment base tables are not exposed as writable entities. Review DAB permissions so the proc runs under a controlled identity without granting applicants direct table access.