0

I manage a REST API that has an interface to POST code from users. This code gets compiled and should send a result to the user but, since compiling can take a long time I prefer to send back to the user a 202 Accepted HTTP code.

On the event the user tries to GET the resource again, what would be appropriate codes both for success, meaning the compilation has been successful, and error, meaning it was not?

Pedro Montoto García
  • 1,672
  • 2
  • 18
  • 38
  • Returning `202 Accepted` seems like a good choice when the resource is not ready yet. See [this question](http://stackoverflow.com/questions/14824969/most-appropriate-http-status-code-for-job-in-progress). Status codes for accessing the resource again? That depends on the semantics of "success" and "error" here. Are we talking about POSTing code to somewhere and then doing a GET later to get the result? –  Nov 18 '14 at 00:48
  • Exactly, I edited the question again to show that. – Pedro Montoto García Nov 18 '14 at 09:21

1 Answers1

1

When doing a GET on that resource after it the compilation is finished, I'd return 200 OK along with a response body indicating the success or failure of the compilation. Here I'll use JSON as the media type. For instance, when compilation was successful you would have this response:

HTTP/1.1 200 OK

{
    "status" : "success"
}

and if the compilation failed you would perhaps include the reason why it failed, maybe taken from the compiler output or similar:

HTTP/1.1 200 OK

{
    "status" : "failure",
    "reason" : "syntax error"
}
  • Using this line of reasoning, if the job is still processing the result would be a `"status" : "working"` or similar I guess. – Pedro Montoto García Nov 18 '14 at 13:24
  • @PedroMontotoGarcía You wouldn't really need a response body in that case since the status code `202 Accepted` already indicates that the resource is being worked on. You still need a body to differentiate the two `200 OK` responses though. –  Nov 18 '14 at 13:28