Ask HN: Should a back end Engineer be able to answer what makes an API RESTful? | Hacker News Reader

Ask HN: Should a back end Engineer be able to answer what makes an API RESTful?

3 pointsCodingChef20 comments

I've been asking this very simple question to many people I've interviewed for a backend position. In my mind this is a warm up question and I never expect the full definition, I'm happy if they just tell me about http verbs and say the keyword "stateless". Unfortunately so many times I had people not being able to tell me anything about it, do you think I should reconsider this question, or is it a fare one?

View on HN

Of course they should. Back-end developers usually build APIs. Hell, I'm a front-end developer and I can easily answer that question. The only thing I can think of is that the people you are interviewing do not have web experience. Are they fresh out of university? I've met plenty of CS students who know all the algorithms and everything about C / C++ but nothing about the web.

That is understandable and I'm not a back end Engineer either. But I had an interview with a back end Engineer with like six years of experience. And I really thought that a simple question like this would make them feel at ease because they would know it right away.

What types of responses do you get?

- what do you mean? - CRUD? - GET, POST, PUT, DELETE

(Question marks are part of the answers, now with the third answer I'm usually fairly happy to begin with and I go into other questions, but that should be the bare minimum).

I've been asked this question as well when interviewing for a frontend position and I just mentioned a few key points and they were very happy about it. But if you're applying for a backend position shouldn't you know more?

According to the person that invented the term "REST", APIs must be hypermedia driven. It goes without saying his definition should outweigh anyone else's. http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...

Anyone that says CRUD or lists HTTP verbs is simply wrong. The term is often abused, and I find that rather disappointing.

Your disappointment is absolutely legitimate. I feel like this term has then be abused a lot, in many write ups as well. I guess from me too. Thanks for pointing it out, I'll make sure to use a different approach in the future that can lead to a better conversation with the interviewee.

I'm an embedded hardware/software developer with only a lightweight exposure to web programming, and I feel that I could answer that question adequately.

I'd be curious to hear the types of responses you're actually getting. I've had to do a lot of interviewing in my career and I've encountered "simple" questions that throw nervous candidates off of their game simply because of a misunderstanding. Sometimes the simplest questions can be the worst because the candidates expect something harder and overthink it. So, you might play with the phrasing a bit, or have different ways of asking it in case they seem to freeze up. For example, "could you name and describe some of the defining properties of a REST API?" or "could you tell me what makes a REST API different from a [SOAP, etc.--pick your favorite alternative] API?"

That said, I would expect a reasonably bright, experienced candidate to understand what you're asking fairly quickly. If you have to re-phrase it 3 times and they're still stuck, they're probably not a good fit.

Thanks for your great input! Multiple times the only answer I got was "CRUD", without any explanation. Which from a certain perspective it relates to REST but from an experienced engineer is expected a little more, nothing specific just anything really.

I think people in this thread are getting a little hung up on the fact that there might not be a clear-cut or widely-accepted definition of "REST". And, sure, if you're only passing people who happen to mention the exact keywords you have in mind, then I'd say your interviewing methodology is flawed.

But I don't think that's what you're doing. I think you're hoping to spark a conversation about what REST is and you've given us a few keywords here as examples of what you might expect to come up in this conversation. And this seems perfectly reasonable to me. I would expect that an engineer with relevant experience and an inkling of insightfulness and professional curiosity would be able to hold such a conversation.

I've seen so many arguments over what is and isn't really REST, I could see this feeling like a minefield type question.

I can see that making it hard to answer.

Quick Google hits on the matter:

https://api2cart.com/api-technology/what-rest-api-really-is

https://www.infoq.com/news/2016/07/microsoft-rest-api/

https://stackoverflow.com/questions/3408191/is-the-twitter-a...

It's CORBA but with limited verbs.

Corba, soap, soa, micro services, rest, ejb's. It's amazing how many times the industry can reinvent RPCs.

No. Anything that can be gleaned from a wiki search, but adds little value to product delivery is useless.

Maybe you can ask the benefits of statelessness, and if the candidates know get and put, which one they'd choose and why.

That's great input thank you, I like your approach much better and it still provides freedom in the answer.

But, REST is a protocol agnostic architecture hat has nothing to do with HTTP verbs, so if your minimum standard is mentioning HTTP verbs, there's a problem...

I see your point. My intention is mostly to spark a conversation but I'm guessing this approach might not be the best. What would you think is a decent question that allows enough freedom in the answer? Unfortunately there's seems to be a lot of confusion about what an answer to my question should be like, not only in this thread but on the web in general. It almost feels like the definition of REST or its idea has been re formulated over the years from the original thesis work. Thanks again for your input!

I don't think asking about REST is a bad question and it's definitely a good inroads to conversation; you should just be aware of both the original work and the variety of different understandings so that you can make good use of that conversation and recognize that skilled candidates are likely to have differing ideas about REST.

I agree with you but my concern is coming from the fact that a lot of people don't have an opinion or idea about it. I understand that there could be different visions, especially different from mine. I'm ok with any opinion in Regards of REST but I guess what I'm trying to understand from this thread is if a backend engineer should have a minimal formulated idea about REST ( which can align with any of the visions we can find with a simple web search), or if it doesn't matter at all. Is it fair to ask this question and expect some sort of vision about REST from an experienced engineer, or should I try to make a more specific question to avoid this confusion altogether?

No matter what, if you're an experienced back end Engineer shouldn't you be able to go over this question without too much trouble or hesitation? Shouldn't you have explored this topic before? Is this a flawed or wrong assumption?

Sorry for the long comment, I'm really appreciating you helping me making this more clear.

If you ask 20 'experts' what REST is you will get 20 different answers with surprisingly little overlap.

You are basically asking them to tell you what your personal definition of REST is. You trying to hire psychics?

It's not a personal definition I'm looking for, I'm pretty sure all of those experts would mention at least once "stateless". And to be honest I would be happy with that, I would just like to get any answer and if it makes sense I'd be ok with that. I'd like to get something reasonable I'm not asking for the Stars.

Have a look at the three links in my comment below. Despite one being entitled "what-rest-api-really-is", pressing Control-F and typing "stateless" doesn't give you a hit.

Reply on news.ycombinator.com