Postel’s Law (aka Robustness Principle) – “Be conservative in what you send, be liberal in what you accept”
This is no longer recommended for at least large, public APIs. Be conservative in what you send, sure, but don’t accept crap. Customers will depend on what you do, not what you say—if you accept things outside your spec, that becomes the spec, and makes it MUCH harder to change implementations or update usage at a later time without breaking users. The best time to fix a broken/sloppy client is before they make any successful calls to your service.
Give specific helpful errors for what you don’t accept.
This is no longer recommended for at least large, public APIs. Be conservative in what you send, sure, but don’t accept crap. Customers will depend on what you do, not what you say—if you accept things outside your spec, that becomes the spec, and makes it MUCH harder to change implementations or update usage at a later time without breaking users. The best time to fix a broken/sloppy client is before they make any successful calls to your service.
Give specific helpful errors for what you don’t accept.