> And I am totally against this. I agree for human / interactive input. But for automated things, be as strict as you can be, and hard fail on anything else. Specs are there for a reason, and not adhering them creates compatibility issues.
Totally agreed on this. When a human inputs a name with a trailing space, trim it for them. Or when they input a phone number with funny dashes, remove them.
But when an API does this, it means the API client is simply incorrect. Incorrect requests should be rejected. Don't leave it up to the server to try to interpret it, this just leads to incorrect behavior.
And I am totally against this. I agree for human / interactive input. But for automated things, be as strict as you can be, and hard fail on anything else. Specs are there for a reason, and not adhering them creates compatibility issues.
> RFC 1122 (1989) expanded on Postel's principle by recommending that programmers "assume that the network is filled with malevolent entities that will send in packets designed to have the worst possible effect
Well, that's gonna be a tough one if you try to make sense of garbage data (or data which doesn't adhere to the specs)
> Protocols should allow for the addition of new codes for existing fields in future versions of protocols by accepting messages with unknown codes (possibly logging them).
I agree with that. That does not mean "be liberal in what you accept". It means the protocol is designed in a better way.
> Basically be liberal in what you accept and conservative in what you send
That's not the same as "be conservative in what you do, be liberal in what you accept from others". "Doing" is a lot more than "sending".
You know.. many programmers sometimes say that when things go wrong it's "a user error", or "a human error". But most of the time it is either a programming error, or a lazy programmer. It's so easy for a programmer to send the correct data. But we live in a world where usually the least correct/secure software is chosen, because it's slightly easier to get started, or allows for input errors (mysql data truncation, mongodb, etc, etc)