Tolerant Reader

A tolerant reader is a client written to read only the parts of a response it actually needs and to ignore everything else, so that an addition on the other side is not an outage on yours. It is the consuming half of the rule that additive changes should be safe: a provider can only add a field without breaking anyone if the people reading it are built to shrug at fields they do not recognise. The failure it prevents is common and avoidable. A parser configured to reject unknown properties turns every additive change upstream into a breaking one, which means a provider doing nothing wrong takes your integration down. The same happens with values rather than fields: code that switches on a status and throws on anything unexpected will fail the first time the provider introduces a new status, and new statuses are the most ordinary kind of product change there is. What tolerance actually means in practice is narrower than it sounds. Read the fields you use and let the rest pass. Treat enumerated values as open — handle an unrecognised one by holding the record for review rather than crashing or, worse, silently mapping it to a default that is wrong. Do not depend on the order of keys or of array members unless the contract states it. Do not treat the absence of an optional field as meaningful. Validate what you consume, not the whole payload. Tolerance has a cost that is worth naming: a reader that ignores everything unfamiliar will also ignore the change you needed to know about. The pairing that resolves this is to be tolerant at runtime and loud in the logs — record unknown fields and unrecognised values so the integration keeps running and a human still learns that the other side moved. That log line is usually how a team discovers a provider shipped something long before any notice reaches them.