1. 2

  2. 3

    I’ve found Postel’s Law to be a source of bugs and complexity in software. IMO, the author is being quite liberal in their interpretation of Postel’s Law and conservative in how they want to apply it. Just making APIs have optional fields seems pretty reasonable. I think this particular point is a subset of Postel’s Law so we should be weary of applying it to any-and-all situations.

    One thing the author does not address, though, is when should those fields become required. Should API versions exist for ever?

    One situation I’m struggling with Postel’s Law is in shipping an appliance to customers. The customer has a lot of power in configuring the appliance, and bricking it is really bad. So what should the system do in a bad configuration? In hosted services, this hasn’t been a problem: configs are strictly enforced and detected and fixed quickly. But in an appliance it’s a little bit more challenging. My current strategy has been to isolate each configuration and write the service that consumes it such that it can make as much progress as possible before giving up. I don’t know if that is a good approach but it keeps the system running, at the cost of more code because there are all these places where errors have to be detected, collected, and reported rather than just letting an error bubble up and terminate the system. In this sense I wonder if something like Lisp conditionals (which I know nothing about) would be a great approach: let the error bubble up and be handled then depending on what the handler does, continue on. I’m basically doing this by hand now, which is going to be error prone.