Comparison
Backward compatibilityvsForward compatibility
Backward compatibility
you add the field as optional so the clients that have never heard of it keep working unchanged.
The property that existing callers keep working against the new version. It is the constraint that governs every API change once you do not control all clients. The practical rules are small: add optional, never remove or rename, never narrow a type, never add a required field, never change the meaning of an existing value.
Full entry →Forward compatibility
your parser ignores fields it does not recognise, so a newer producer can add one without breaking you.
The property that old code tolerates data produced by newer code. It is achieved by ignoring unknown fields rather than rejecting them, and by never depending on the absence of something. It is what makes rolling deploys safe, because for a while both versions are reading each other's writes.
Full entry →