Hacker News Reader

Comment by contrahax | Hacker News Reader

This article is really making a lot of broad assumptions about what people are making APIs for and how people write code.

"Now you hit an API that has to do some async behaviour and now your screwed. There are some solutions for that but they make the code really complex, even Node.js."

What does that even mean?

View on HN

I don't know what he meant, but we have a situation where our REST API needs to reply with “I see you want to get X. Come back and ask for X again when it's ready.“. In our backend, we just add the task in message queue.

I never had a problem with this.

The protocol I wrote just sent a job-ID to the client and the client started polling for the result.

Since AJAX is already asynchronous I could write a JavaScript library for the browser, which made the whole thing transparent for the client.

The only problem I ran into were multiple long running jobs, which caused parallel polling. But since the communication between server and client was hidden behind the client-lib, I could change the protocol later, to merge multiple polling requests in one etc.

HTTP 202 Accepted [1] does the job.

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10...

Actually it doesn't. The "hard" problem here isn't telling the client to come back later, it is providing the client with a way to get the actual results later. So providing a request identifier that gets populated in a database when the task is complete may be one way to do that.

  → POST /resource
  ← 202 Accepted
  ← Location: /jobs/XXX

Right but you need /jobs/XXX to return a response that is not 404. How you accomplish this is outside the scope of what 202 provides you.

It means he had a problem and so will you. I'll stop short of calling it a profoundly disturbing assumption, but it pervades the entire article.

Reply on news.ycombinator.com