Here's why the Robustness Principle isn't just a TCP relic it's a survival skill for modern API design.
A guide for anyone building resilient, future-proof systems 👇
The Robustness Principle Be conservative in what you do, be liberal in what you accept from others was originally formulated during the development of TCP. Yet its relevance continues, especially when designing and maintaining modern JSON-based APIs.
🔍 Understanding the Principle
At its core, this principle advises:
-Clients should strictly follow the API specification send only what's documented and expected.
-Servers, on the other hand, should accept input that may not fully align with the spec, as long as the intent is clear and the input isn't malicious.
This balance between precision and flexibility creates robust, maintainable systems that adapt well to change.
💻 Why This Matters for JSON APIs
Modern APIs, especially those using JSON, benefit significantly from this approach.
-What happens if a client sends a payload with more fields than expected?
-What if fewer fields are included?
A flexible API should not break in these cases. If required fields are present and valid, extra or missing optional data should not cause failure.
📨 Accepting ≠ Processing
Accepting data doesn't mean the server has to process all of it. JSON's structure allows extra fields to exist in requests without requiring the server to act on them.
This is especially useful when multiple teams are working on different parts of a system. A server that tolerates unknown fields allows client updates to happen independently - no need for tight coordination.
🛑 Required, Conditional, and Default Fields
One common mistake is assuming every request must include a complete JSON object. But APIs should be designed to tolerate:
-Extra fields,
-Partial data,
-And missing optional values - as long as required fields are present.
Define which fields are required, conditionally required, or can default to a preset value. This allows clients to focus only on what's relevant to them and supports seamless field additions in the future.
Do you want to force every client to update when you add a new field?
Or can you use a smart default so only the interested users adapt?
In general, the less coordination needed between updates, the better.
🔒 Flexibility ≠ Insecurity
Being flexible doesn't mean being careless.
You should:
-Enforce data type and size limits,
-Validate every field before processing it,
-And always check required fields are present.
If a field should be a date, it must match a valid date format.
If it's a number, it should behave like one.
Flexibility means accepting additional data, not blindly trusting it.
🔄 Internal APIs Matter Too
It's easy to apply these ideas to public APIs and forget about internal ones. But internal APIs - especially in microservice architectures - are just as prone to compatibility and maintenance issues.
Apply the same principles internally. Doing so makes your system easier to update, extend, and maintain - without unnecessary bottlenecks.