4 ms·

I've always felt that this was a misguided principle, to be avoided when possible. When designing APIs, I think about this principle a lot. My philosophy is mo

I've always felt that this was a misguided principle, to be avoided when possible. When designing APIs, I think about this principle a lot. My philosophy is more along the lines of "I will begrudgingly give you enough rope to hang yourself, but I won't give you enough to hang everybody else."

joshstrange 2y ago
When it comes to writing APIs I feel strongly that you should be incredibly strict. 1 != ‘1’ true != 1 true != ‘true’ undefined != false undefined != null etc “Flexibility” in your API just means you are signing up for a maintenance burden for the lifetime of your API. You will also run into problems because you have to draw the line somewhere and people will be frustrated/confused since your API is “flexible” but not as flexible as they want. Better to draw the line at complete strictness IMHO. I dislike even optional fields and prefer null to be passed instead except special cases (like when null has a meaning, example: search endpoint where you pass the fields you want to search on and a field can have a null value). I want people to be explicit about what they are doing/fetching when using an API I have written/maintained. It also encourages less sloppy clients
quesera 2y ago
HTML parsing is the modern-ish layer-uplifted example of liberal acceptance. I won't argue that this hasn't been a disaster for technologists, but there are many arguments that this was core to the success of HTML and consequently the web. Which, yes, could be considered its own separate disaster, but here we are!
- pas 2y ago
  It makes sense in a "costumer obsessed" way. The user agent tries to show content, tries to send requests and receive the response on behalf of the client (costumer), and ceteris paribus it's better for the client if the system works even if there's some small error that can be worked around, right? but of course this leads to the tragedy of anticommons, too many people have an effective "veto" (every shitty middlebox, every "so easy to use" 30 line library that got waaay to popular now contributes to ossification of the stack. what's the solution? similarly careless adoption of new protocols? and hoping for the best? maybe putting an emphasis on provable correctness, and if something is not conformant to the relevant standard then not considering it "broken" for the "if it ain't broken don't touch it" principle?

joshstrange 2y ago

When it comes to writing APIs I feel strongly that you should be incredibly strict. 1 != ‘1’ true != 1 true != ‘true’ undefined != false undefined != null etc “Flexibility” in your API just means you are signing up for a maintenance burden for the lifetime of your API. You will also run into problems because you have to draw the line somewhere and people will be frustrated/confused since your API is “flexible” but not as flexible as they want. Better to draw the line at complete strictness IMHO. I dislike even optional fields and prefer null to be passed instead except special cases (like when null has a meaning, example: search endpoint where you pass the fields you want to search on and a field can have a null value). I want people to be explicit about what they are doing/fetching when using an API I have written/maintained. It also encourages less sloppy clients

quesera 2y ago

HTML parsing is the modern-ish layer-uplifted example of liberal acceptance. I won't argue that this hasn't been a disaster for technologists, but there are many arguments that this was core to the success of HTML and consequently the web. Which, yes, could be considered its own separate disaster, but here we are!

pas 2y ago
It makes sense in a "costumer obsessed" way. The user agent tries to show content, tries to send requests and receive the response on behalf of the client (costumer), and ceteris paribus it's better for the client if the system works even if there's some small error that can be worked around, right? but of course this leads to the tragedy of anticommons, too many people have an effective "veto" (every shitty middlebox, every "so easy to use" 30 line library that got waaay to popular now contributes to ossification of the stack. what's the solution? similarly careless adoption of new protocols? and hoping for the best? maybe putting an emphasis on provable correctness, and if something is not conformant to the relevant standard then not considering it "broken" for the "if it ain't broken don't touch it" principle?