A legacy inspection API returns HTTP 200 with an error string in the body. Mobile clients need proper 4xx/5xx status codes and a cleaned JSON shape without rewriting every backend method yet. What should developers use?
Select an answer to reveal the explanation.
Short Explanation
The old inspection API smiles with a 200 while whispering "error" in the body — mobile apps hate that. Use API Gateway mapping or response overrides to fix the status and JSON at the edge. You get cleaner clients without rewriting every backend method today.
Full Explanation
When an old inspection API returns HTTP 200 with an error object in the body, mobile clients cannot rely on status codes for failure handling. Developers should use API Gateway mapping templates or response overrides to translate upstream payloads into correct HTTP status codes and JSON shapes at the edge. That adapter layer modernizes a legacy municipal backend without an immediate rewrite: true failures become 4xx/5xx, successful inspections stay 200 with a clean body, and client SDKs behave predictably.
Amazon CloudFront alone does not rewrite upstream application status codes into proper semantics merely by caching. AWS WAF converting application errors into HTTP 200 success responses would hide failures and is the opposite of correct status mapping. Leaving the lie-in-the-body pattern untouched forces every client to parse proprietary error envelopes and breaks standard telemetry that keys off status codes.
Exam caveat: response mapping is an anti-corruption layer, not an excuse to leave broken backends forever. Prefer fixing the origin when you own it; use Gateway mapping when you must adapt during migration. Do not map real 500s into 200s to “keep dashboards green.”
Operational check: catalog legacy success-with-error payloads; implement Gateway mappings that set status from payload fields; contract-test mobile clients against mapped responses; monitor 4xx/5xx rates as true signals; and schedule origin remediation so mapping complexity can shrink over time.