CODEWITHSUNDEEP
restasynchronous
Steve D
Steve D

Reputation: 393

Long GET request on REST API, handling server crashes

I have a REST API where the GET request can take 10-20 seconds. So I usually return a 202 code with a location like http://fakeserver/pending/blah where the client can check the status of this request. pending/blah returns a 200 code with "Status: pending" if the request is still pending, and a 303 code when it's done, with a final location for the result: http://fakeserver/finished/blah .

But what if the server crashes during the request processing? Should pending/blah return a 303 code, and then finished/blah returns a 404? How can I alert the client that the resource may be available at a location, but I'm not sure? Assume the requests are persistent, so that when the server reboots, it continues processing the request.

Upvotes: 0

Views: 1319

Answers (1)

Opal
Opal

Reputation: 84854

First of all I'll make the state of processed resource an internal field of this resource. This way you can avoid using strange endpoints like: /finished/blah/ or /pending/blah/ and instead of it introduce a single endpoint /resources/blah/ which will among other fields return the state it's currently in.

After changing architecture to the endpoint mentioned above if you ask for blah and server has crashed you can:

  • return 200 with pending status - client doesn't have necessarily to know about the crash
  • return 404, simple not found with and extra message that server has crashed.
  • return 500 and inform the client explicitly what the problem is.

Other useful codes may be also 409 or 503. Returning any 3XX is not a good idea IMO since no redirection applies here. Personally I'd go for 200 or 500(3).

Upvotes: 1

Related Questions