High Scale REST API

Question

One of our REST APIs will cause a long-running process to execute. Rather than have the client wait for a long time, we would prefer to return an immediate response.

So, let's consider this use case: An applicant submits an application, for which there will be an eventual result. Since this is a very high-scale platform, we cannot persist the application to storage, but must place it onto a queue for processing.

In this situation, is it acceptable practice to return the URI where the application will eventually live, such as http://example.com/application/abc123?

Similarly, would it be acceptable practice to return the URI of the result document, which represents the decision regarding the application, as part of the representation of the application resource? The result document will not be created for some minutes, and an HTTP GET to its URI (or the URI of the application for that matter) will result in a 404 until they are persisted.

What is the best practice in this kind of situation? Is it acceptable to hand out "future" URIs for resources?

Answer 1

I don't see anything wrong with such design, but have a closer look at the list of HTTP status codes for better responses. IMHO the first request should return 202 Accepted:

The request has been accepted for processing, but the processing has not been completed.

while requests to the URL where the result will eventually be should in the meantime return 204 No Content (?):

The server successfully processed the request, but is not returning any content

And of course it should eventually return 200 OK when processing finishes.