#15 | Postel's Law in Software Engineering

Postel law states that:

Be conservative in what you send, be liberal in what you accept

Let’s break it down:

Taking client-server architecture as an example, this means:

• Ensure the API responses strictly adhere to the defined specification.

• Avoid adding unnecessary fields or data in responses that might cause confusion.

• Use clear and consistent formats for dates, strings, numbers, etc.

Below is an example where this gets “violated”:

The server sends an extra field in the payload that the client does not expect - not conservative.

• Allow clients to send data slightly outside the expected format, as long as it can be interpreted without ambiguity or errors.

• Handle missing fields gracefully by using default values or ignoring unrecognized fields instead of rejecting the request outright.

• Support backward compatibility when adding new fields or features.

An anti-example of this is something I experienced a few days back:

I was exploring Hugging Face blogs and for no reason thought of tinkering with the page parameter in the URL.

With p=0, it should show page 0 of the blog - and it does.

But if p=-1, it gives up - and doesn’t show any article other than the first one.

Ideally:

page should be max(p, 0)

Here:

Hugging Face fails to be liberal in accepting requests

Other real-world examples could be:

Eg: Google / Bing

Search engines handle poorly structured or misspelled queries gracefully:

• Searching for "whats teh time" still gives accurate results.

• Invalid or extra URL parameters (like tracking codes) are often ignored.

Eg: Microsoft Word / Google Docs

Word processors open slightly corrupted or outdated document formats and attempt to recover data.

Eg: Google Maps / Apple Maps

These apps correct small user input errors:

• If you search for “Starbukcs,” Google Maps suggests “Starbucks.”

• Extra or invalid query parameters in URLs don’t break functionality.

Thanks for reading. Until next time