Hacker News Reader

Comment by daGrevis | Hacker News Reader

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.

View on HN

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.

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.

Reply on news.ycombinator.com