Home/ Questions/Q 8651197
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-12T14:00:17+00:00

One of our REST APIs will cause a long-running process to execute. Rather than

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    From “RESTful Web Services Cookbook“

    Problem

    You want to know how to provide resource abstractions for
    tasks such as performing computations or validating data.

    Solution

    Treat the processing function as a resource, and use HTTP GET to fetch
    a representation containing the output of the processing function. Use
    query parameters to supply inputs to the processing function.

    This entails just GET requests on a URI that represents the processing function. Your example ‘http://example.com/application/abc123‘ URI. When returning a response you would include what information you have by now and use HTTP codes to indicate the status of the processing as already suggested by Tomasz.

    However…, you should not use this approach, if the subsequent application processing stores or modifies data in any way.

    GET requests should never have side effects. If the submittal of the application leads in anyway (even if only after being processed in from queue) to new information / data being stored, you should use a PUT or a POST request with the application’s data in the request’s body. See “Why shouldn’t data be modified on an HTTP GET request?” form more information.

    If they application’s submittal stores or modifies data, use the pattern for asynchronous processing: a POST or PUT request with the application’s details.

    For example

    POST http://example.com/applications

    which returns “201 Created” with the URI of the new application resource.

    or

    PUT http://example.com/applications/abc123

    which returns “201 Created” and

    Both would also return any resource information that is already known at that time.

    You can then safely perform GET requests on the URI of the new resource as they now only retrieve data – the results of the application processing so far – and no data is stored or modified as a result of the GET.

    To indicate the application’s processing progress, the GET request can either return some specific status code in the response (queued, processing, accepted, rejected), and/or use the HTTP response codes. In either case a “200 OK” should only be returned when the application’s processing is complete.

    • 0