Update on Driving Client Resiliency: How we enforced Postel’s Law by violating Postel’s Law

Over three years ago, we embarked on an experiment of utilising counter-measures to prevent badly written clients to our RESTful APIs.

Bad clients are ones that make unhealthy assumptions about property ordering and presence, and violate Postel’s Law, thus creating a blocker to having evolvable APIs.

Since then, new APIs that we’ve released have implemented these counter-measures (which we’ve open-sourced here) and I’m happy to report that they seem to be working.

I say seem, as it is difficult to prove empirically — as these are new APIs we don’t have the data to compare before/after — however, anecdotally, the noise around clients breaking due to unhealthy assumptions on these APIs has been zero.

This makes intuitive sense, as no integration would pass even basic testing by the integrator if it relied on property ordering or presence as the counter-measures randomises ordering, optional property presence and adds random keys and values to the responses. Essentially this forces clients to follow Postel’s Law and be tolerant to non-breaking changes.

As a result, we’ve mandated that all of our APIs will be utilising these countermeasures going forward.