The city’s license API must introduce a breaking change to the permit payload. Independently deployed mobile and kiosk clients still call the current contract. What is the sound migration approach?
Select an answer to reveal the explanation.
Short Explanation
Think of renaming a street while people still have the old address on their mail. You post the new street name but keep delivering to the old one until everyone updates—then retire the old route.
Full Explanation
Independently deployed mobile and kiosk clients cannot all cut over the instant a breaking permit payload ships. Publish a new major version or path, keep the prior contract alive, and migrate callers on their own release schedules before retiring the old endpoint. That preserves independent deployability for the city’s license API instead of synchronizing every consumer into a big-bang outage.
Overwriting the existing endpoint in place and hoping clients notice at runtime breaks callers that have not upgraded and turns a planned change into production failures. Changing field meanings silently while keeping the same path and version number is a contract lie—clients parse old semantics against new data. Deleting the old endpoint the same day the new one ships forces upgrades on every client simultaneously and defeats the point of separate deployables.
Exam caveat: dual-running versions has a cost (two code paths, dual tests); set a published deprecation window and metrics on old-version traffic rather than running forever. Operational check: route a canary percentage of traffic to the new version while monitoring 4xx/5xx and client version headers, and only remove the old path after old-version request rate falls below an agreed threshold.