A election office automation team must integrate county scripts with a controller northbound API that returns structured objects for inventory and health. Which data encoding is the most common fit for that REST-style integration?
Select an answer to reveal the explanation.
Short Explanation
Controller APIs speak the same language web apps do: JSON. It is curly-brace structured data your Python scripts chew into dicts and lists. Syslog novels, serial bitstreams, and print jobs are not how modern civic automation talks to controllers.
Full Explanation
Election-office automation integrating with a controller northbound API that returns structured objects for inventory and health most commonly consumes JSON payloads that scripts parse into nested objects and arrays. REST-style civic integrations standardize on JSON because it maps cleanly to Python dicts/lists and to most controller OpenAPI documents. That encoding fit is what the stem asks for.
Unstructured free-text syslog lines lack schema for reliable inventory objects. Raw HDLC bitstreams from WAN serial interfaces are not a northbound controller API encoding. PostScript print jobs from election printers are unrelated to controller health integration.
Exam caveat: some APIs offer XML as an alternate representation, but JSON remains the most common REST integration choice in EI programmability scenarios—do not confuse wire encoding with YANG XML used on NETCONF. Operational check: authenticate to the controller, GET a sample inventory resource, parse JSON keys needed for the county script, and assert required fields exist before scheduling production jobs. Store sample payloads in the automation repo as contract fixtures for the election network. Record the chosen control and the rejected alternatives in the municipal change record so future on-call staff understand which failure modes were avoided for city services.