4 ms·
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 rea
by daGrevis 13y ago
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.
- k__ 13y agoI 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.
- thibauts 13y agoHTTP 202 Accepted [1] does the job. [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.3 http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10...
- jeremyjh 13y agoActually 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.
- icebraining 13y ago→ POST /resource ← 202 Accepted ← Location: /jobs/XXX
- jeremyjh 13y agoRight 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.