Prayag's profile picture

📸 My Alter Ego!

Prayag Dave

Building
scalable 
solutions
BACK

Postel’s Law and APIs: Why Being Flexible Matters

4 min read

•

0 views

Have you ever built an API and wondered, "Should I be strict with what I accept or more forgiving?" Well, that's exactly where Postel’s Law (also called the Robustness Principle) comes in.
"Be liberal in what you accept, and conservative in what you send."
Jon Postel, one of the pioneers of the internet, came up with this rule while working on TCP/IP, and honestly, it’s just as relevant today—especially when designing APIs.
Let’s break it down and see why it matters.

✅ Be Liberal in What You Accept

Think of your API as a great host—one that doesn’t freak out just because a guest shows up wearing mismatched socks. Your API should gracefully handle minor variations in requests instead of rejecting them outright.

Examples:

Extra Fields? No Problem.
  • A client sends GET /users/123?unusedParam=true.
  • Instead of throwing an error, your API just ignores unusedParam and processes the request normally.
Different Date Formats? Accept Them.
  • One client sends GET /users?registered_after=2024-01-01, another sends GET /users?registered_after=01-01-2024.
  • Instead of rejecting one, your API should normalize the format internally.
Case Sensitivity? Don’t Be Picky.
  • Someone sends { "name": "ALICE" }, another sends { "name": "alice" }.
  • Your API shouldn’t care—it should handle both consistently.
By being flexible, you avoid unnecessary client-side errors and make integration way smoother.

❌ Be Conservative in What You Send

Now, while your API should be forgiving with what it receives, it should be very careful about what it sends back. Think of it like this: you wouldn’t give someone a different home address every time they ask, right?

Examples:

Consistent JSON Structure
If your API response is:
  • It should stay that way—even if you later add new fields.
Don’t Rename or Remove Fields Randomly
  • If a client is expecting "name" and "email", suddenly changing it to "fullName" and "contact" will break their app.
Versioning Is Your Friend
  • If you really need to make breaking changes, use API versioning (/v1/users vs /v2/users) instead of messing with existing responses.
When your API response structure is predictable, developers trust it more and avoid unnecessary debugging nightmares.

🌍 Real-World API Example

Let’s say I’m building a User Profile API where clients fetch user details like this:

Client Request:

What My API Accepts:

✅ Works fine even if the request has extra parameters (?sort=asc or ?foo=bar).
✅ Accepts different date formats for filtering (YYYY-MM-DD, MM-DD-YYYY).

What My API Sends Back:

✅ Consistent structure, no unexpected renames or removals.
✅ If new fields are added, existing ones stay the same.

Why Postel’s Law Makes Your API Better

  • More Developer-Friendly – Clients don’t need to worry about every tiny request variation.
  • Fewer Breaking Changes – Your API remains backward-compatible, preventing unnecessary headaches.
  • Better Interoperability – Different teams or services can interact with your API without struggling with rigid rules.

Summary

Postel’s Law might sound simple, but trust me—it’s a game changer when building reliable, flexible APIs.
Rule of thumb:
  • Be forgiving with inputs.
  • Be predictable with outputs.
Stick to that, and your API will be much easier to use and maintain. Happy coding!