Great work! Are there similar initiatives trying to collect common knowledge in structured data? (I know this is a broad topic, but can't stop thinking about a more semantic web.)
I doubt it. I've found that the vast majority of jobs only shallowly interact with technologies. When they say they want someone with Microsoft Office skills, they don't mean they need someone who can hack and extend it programmatically, they just want someone who can fluently work with documents. They don't want to have to hold your hand on basic tasks.
If they really do want someone like this, chances are you can figure it out by going to the company website and figuring out what problem they're trying to solve. They might be writing a web browser, for instance, in which case, yes, they do need someone with a deep knowledge of HTTP.
But even then, it's usually not a requirement, but more of a wish-list sort of thing. I had a job at Panasonic doing browser testing, writing, performing and automating. My meagre understanding of the way the Internet worked and programming knowledge was more than sufficient, it's much harder to find good people than you think.
If I saw "significant HTTP knowledge" on a job app, I'd go bone up on the fundamentals the night before I go in for an interview. That's really all "significant" means. If you can discuss the meanings of the different verbs and when and why you'd use each of them, you'd be far ahead of their expectations.
Personally, I like using HTTP principles when interviewing web developer candidates. I'm not expecting people to know every detail of every RFC, or trivia type stuff in general. I more am interested in how much they know / can figure out about how HTTP-based communication works. I will ask stuff like "Explain how a redirect works, and how clients/browsers and servers interact with each other during a redirect." Also, REST is built on the concept of using HTTP verbs and resources properly, so it is nice to ask them to design a rough draft of an API to edit, add, delete, and list users via HTTP. Without asking them to do it RESTfully. It's telling if their first instinct is to have a "createUser" endpoint versus a POST to /users/
> It's telling if their first instinct is to have a "createUser" endpoint versus a POST to /users/
It's telling of what exactly?
RESTful is just one style of creating application interfaces over HTTP. And as far as I know, web apps with true RESTful interfaces are somewhat rare. [1] If you don't ask the candidate to do it RESTfully, it seems like you're doing the common interview anti-pattern of asking a question that is open-ended but expecting a particular answer.
That the candidate favors transport-agnostic APIs or has limited familiarity with HTTP. One easy follow-up: "I notice you decided to call the method createUser..." and you've learned something concrete. They'll either stare blankly or discuss their preference for JSON-RPC or SOAP or whatever.
> And as far as I know, web apps with true RESTful interfaces are somewhat rare.
It's common to take advantage of HTTP's verb syntax.
It's telling that they don't know (or do know, but don't see the benefit in) RESTful interfaces. Which isn't a dead-end for the interview, it just leads to more questions to see what they understand about HTTP. I'm not expecting a particular answer, I'm using a question to understand where someone is at and then using the following discourse to understand how they arrived there.
If you're just looking for HTTP codes, here's the link to the JSON file: https://github.com/andreineculau/know-your-http-well/blob/ma...