0

I am trying to design a RESTful api for a service that accepts a bunch of parameters and generates a large result. This is my first RESTful project. One tricky part is that the server needs some time (up to a few minutes) to generate the result. My current thought is to use POST to send in all the parameters. The server response can be a job id.

  1. I can then retrieve the result using GET /result/{job_id}. The problem is that the result is not available for the first few minutes. Maybe I can return the resource unavailable at the beginning and the result once it is available. But this feels odd and add some odd logic in the client.
  2. An alternative is to retrieve the job status GET /job_status/{job_id}, where the result might be running/error/done, similar to the http status code, where done status also comes with a result_id. Then I can retrieve it with GET /result/{result_id}.

Either case has some problem with what I have read about GET. In both cases, GET result is not fixed and not cacheable at the beginning while the job is still running. On the other hand, I read somewhere that it is OK to do things like GET /currentWhether or Get /currentTime, which are similar to at least my second approach. So my questions are:

  1. Which one is better? Why?
  2. Should I use GET for such situation?
  3. Or neither one is OK? What would you do?

Thank you very much.

Should I use GET?

zggame
  • 969
  • 2
  • 9
  • 15

1 Answers1

1

For long running operations, here is an approach which tells setting expire or max-age headers to your response properly.

Here is the example Best practice for implementing long-running searches with REST

But I recommend The RESTy Long-op Protocol for your case.
Your solution will be more robust and more client friendly.

Community
  • 1
  • 1
talipkorkmaz
  • 332
  • 2
  • 7