Postel’s Law, also known as the Robustness Principle, originates from Jon Postel’s design philosophy for the early Internet (RFC 761):
TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.
Be Liberal in What You Accept (Input)
- Your API should tolerate minor deviations or additional unexpected fields in requests.
- Backward compatibility: Accept older clients with missing or extra fields.
- Be resilient to format variations (e.g., optional query params, flexible enum values).
{
"name": "Nimendra",
"email": "nimendra@example.com",
"nickname": "Nim" // not expected
}Be Conservative in What You Send (Output)
- Send only strictly defined and documented responses.
- Do not include extra fields that clients might not expect.
- Stick to stable formats and schemas, especially in production.
// Expected JSON Output
{
"userId": "123",
"name": "Nimendra"
}
// Client doesn't expect Following
{
"userId": "123",
"name": "Nimendra",
"debugInfo": "internal-xyz" // client doesn't expect this
}
Criticism
While helpful, Postel’s Law can backfire if taken too far:
- Accepting bad input encourages sloppy client behavior.
- Makes debugging and enforcement harder.
- Some suggest being explicit and strict even on input (e.g., OpenAPI validation).