Tolerant Reader

Overview

The Tolerant Reader pattern applies Postel's law to integration: be conservative in what you send and liberal in what you accept. A consumer reads the minimum it needs and ignores everything else, which makes additive changes safe.

How it works

Instead of deserialising a response into a class mirroring the entire provider schema, the consumer picks fields.

// strict: fails on any unknown property
Order o = mapper.readValue(json, Order.class);

// tolerant: select what is needed
id     = json.path("id").asText();
amount = json.path("total").path("amount").asLong();
status = parseStatus(json.path("status").asText("UNKNOWN"));

With JSON binding libraries, disable fail-on-unknown-properties. With Protobuf and Avro, rely on built-in unknown-field handling and schema resolution. For enums, map unrecognised values to UNKNOWN and choose a safe behaviour. Consumer-driven contracts, for example Pact, record the exact fields each consumer uses so providers see what is safe to change.

Pitfalls

• Defaults that mask absence. Distinguish optional from required fields and fail loudly when a required one is missing.
• Crashing on new enum values. Always include a default branch.
• Tolerating changes in meaning. A field changing units is a breaking change no reader can absorb.
• Applying tolerance to untrusted input. Inbound requests to your own service should still be validated strictly.
• Skipping contract tests, leaving real dependencies unrecorded.

Key takeaways

• Read only needed fields; ignore the rest.
• Handle unknown enums and absent optionals safely.
• Be strict about what you require, lenient about what you do not.
• Back it with consumer-driven contract tests.