A client or service expects changes to occur in a message or media type it receives.
How can clients or services function properly when some of the content in the messages or media types they receive is unknown or when the data structures vary?
Rarely can a single software release produce service messages or media types that address all future client needs. For the service owner, it is usually more effective to deliver small incremental pieces of functionality over time, and let the Service API evolve naturally. Unfortunately, this introduces the possibility for breaking changes in clients as data items are added, changed, or removed from service messages.
Service owners often have to deal with message variability as well. For example, some message structures may be owned and designed by business partners, industry consortium, or trade groups. In situations like these, service developers may not be able to keep up with client applications that adopt newer versions of these messages. The service must therefore be forward compatible and accept client content that it may not fully understand.
How can clients continue to process service responses when some of the content is unknown or the data structures vary, and how can services deal with changing client request messages?
Design the client or service to extract only what is needed, ignore unknown content, and expect variant data structures.
Tolerant Readers extract only what is needed from a message and ignore the rest. Rather than implementing a strict validation scheme, they make every attempt to continue with message processing when potential schema violations are detected. Exceptions are only thrown when the message structure prevents the reader from continuing, or the content clearly violates business rules. Tolerant Readers ignore new message items, the absence of optional items, and unexpected data values as long as this information does not provide critical input to the service logic.