1. 4

  2. 4

    I’m a bit of a skeptic of Postel’s law as a guiding principle. And I’m not even talking about in the sense of “it’s a good rule of thumb, but obviously there are exceptions.” I mean that I actually think it might be the wrong idea in some contexts.

    In the context of something like a REST API, I can understand maybe ignoring JSON fields that you don’t need. But if someone sends a JSON body when you don’t expect anything at all? I think it’s pretty clear that the client misunderstands the API and almost anything you do is likely not what they expect. Same thing with sending extra query parameters. If they sent them, then they probably expect them to affect the results. Is it really best to let the client think they succeeded when they probably didn’t succeed in what they expected?

    1. 2

      I agree that the implementation of an external SaaS API implementation seems like the wrong place to aggressively apply Poster’s Law.

      We need to differentiate between two interpretations of “robustness”:

      1. The program accepts as many inputs as possible that could be conceivably valid.
      2. The programs accepts inputs in such a way that maximises the chance that its behaviour is correct.

      Postel’s Law seems to strongly advocate for the former, but I think the latter is actually much more helpful for API consumers. (Generally, I would argue that (2) is the better thing to optimize for whenever your program could have side effects, such as “being billed for an API call” or “modifying user data”.)