County mobile inspectors need to create and read permit resources over HTTP using JSON payloads in a common modern API style. Which approach matches that requirement?
Select an answer to reveal the explanation.
Short Explanation
Inspectors just want clean HTTP calls that say "here's a permit resource" and get JSON back—classic REST. It is the common modern style for mobile and web clients talking to cloud APIs. You do not need SOAP envelopes or overnight file dumps for that day-to-day pattern.
Full Explanation
County mobile inspectors who need to create and read permit resources over HTTP using JSON payloads in a common modern API style should expose resource-oriented REST web services over HTTP with JSON representations. REST-over-HTTP with JSON matches CRUD-style mobile integrations commonly tested for municipal field workflows. Requiring every client to open a persistent bidirectional socket before any CRUD call describes WebSocket-style interaction beyond the stated requirement. Shipping only SOAP XML envelopes with mandatory WS-Security for each mobile screen is a heavier legacy style than the scenario asks for. Replacing HTTP APIs with nightly CSV drops to each inspector tablet abandons interactive create and read operations. Exam caveat: REST is resource-oriented; not every HTTP API is RESTful—RPC-over-HTTP and GraphQL also use HTTP but differ in client interaction style. Operational check: exercise GET/POST on permit resources with JSON, verify status codes and auth via the municipal API gateway, version the interface, publish OpenAPI documentation for inspector app developers, and monitor error rates after release. In municipal cloud operations, record the chosen control and the rejected alternatives in the change or incident ticket so future on-call staff understand which failure modes were avoided for city services. Re-validate after the next maintenance window that the same decision still holds under current provider limits, identity bindings, and application versions used by the civic platform team.