This evening I’ve been coding up something on a tight deadline. A few minutes ago I wrote a function named:
REST is an acronym for… you can look it up if you care. It’s a way for code running in your browser to communicate with services off somewhere else. Some guy got his Phd making this nonsense up, and it has now become an industry standard. That guy is very lucky I was not one of the ones to review his dissertation, and the rest of the world is very unlucky that I wasn’t.
Like with HTML before it, someone came up with a half-assed solution to a real problem, and before the smart people in the room could say, “hey, that has some pretty serious flaws, but with only a little more effort we could fix most of them” the whole world went romping off with the flawed solution. And here we are.
Not only does REST violate previously-existing standards, it does so for no technical advantage. Servers and programming languages had to be updated to accommodate those violations. Maybe that should have been a red flag.
It would be SO DAMN EASY to fix most of the problems with REST. Use your head(ers)!
But here we are sweating over REST. And here’s a fun thing: for no technical advantage people who use this standard-violating standard have to understand the rules of pluralization in American English. At least in any implementation of REST I’ve had the pleasure of working with. Not only is that fucking annoying, it’s exclusionary. Sorry, kid in Senegal, we’re making a standard that disadvantages you.
Sure, you can get a code library to do plurals for you, and with any luck the rules in the browser code will match the rules on the server. Up until now, I’ve chosen the approach, “always name your data types in a way that just adds ‘s’ for the plural.” Tonight that wasn’t an option, so I a made a way for specific REST servers to keep only the rules relevant to them. More efficient and more reliable than someone else’s library.
And as I’ve often said, your code should express what it does without resorting to comments.