Readit NewsI see a lot of people here questioning the wisdom of the rule, however, like every other principle used in SWE, it shouldn't be applied blindly. Ask yourself "why am I specifying that a maximum of five wangervanes can be specified in the turboencabulator settings?" _IF_ you have a good reason, fine. Most of the time you will not.
What theoretical merit? It sounds like a completely made up rule of thumb based off of a persons anecdotal experience.
Just like every other heuristic in software engineering, its not a silver bullet, but generally speaking, this principle will serve you well.
I don't understand: An API is an application programming interface, i.e. it is meant to be consumed by other programs. How does that go together with
> REST and HATEOAS are for humans
?
And how does that go together with the requirements of "no interpretation needed" and therefore "little coupling" between client and server that were mentioned in the article? Any API must be interpreted by the calling application – i.e. the caller must know what they are calling and what responses they might get. Otherwise they cannot do anything useful with it – at least not in an automatic (programmatic) fashion.
I really don't understand how something can be a REST API on the one hand (clear, well-documented interface; used for programming), and on the other hand is supposed to be "for humans" and devoid of "interpretation" on the client's part. (Leaving aside that, even if this were possible, the interpretation would simply be done by the very final client of the API: The human.)
All in all, I simply fail to see how ideas like "REST is for humans", HATEOAS etc. are supposed to be actionable in the real world.
99.9% of folks hiring SREs or starting SRE teams haven't read the SRE book.
The SRE book (and its sequels) say quite plainly what SRE is and isn't. They also say that not every org is going to be exactly like google so no, "we're not google" isn't an excuse.
the E in SRE is for engineering. As in software engineering. SREs are software engineers. Or should be. If your SREs don't know basic SWE principles, they're not SREs. If your org isn't applying software engineering principles to minimizing operational complexity at scale, your org isn't doing SRE.
I'm constantly shocked by how hard these things are to grasp, even for most SREs. If the problems I (occasionally) get to solve weren't more interesting than most regular product work, I'd get out of "SRE" entirely.
"Let me tell you about the years of physical/emotional/sexual abuse I've suffered though." That's just not going to happen - and if it did happen the interviewer is probably not going to come away with "What a brave person to overcome all of that!" but "What a damaged person, I don't need them around".
Well done, you've weeded out people who've already suffered enough.