Asynchronous request-reply using LabVIEW Web Services

[TurboPhil]

Are there any examples in the wild of the async request-reply pattern with LabVIEW web services.

As mentioned in this related post, I have some web service methods that take a fairly long time to execute, and I'd like to provide some intermediate status updates while they are running, but reserve the right to return a failure code (i.e. HTTP status code 500, or similar) if the process fails at any point.

Looking for any examples where folks might have successfully accomplished this via redirects and async request-reply. Or any other means.

[Jorn_Deruyck]

I've done something similar for the software I'm working on.

It consists of a QSM that takes care of the asynchronous requests:

When a call is made to web resource handler, this request is passed to the queue of this QSM, and a redirection code is returned that points to a separate resource called /operations

This resource lists all pending, current and previous operations that were forwarded to the QSM

Each operation is identified with its unique id, and the redirection also points to this specific id: /operations/{id}

An individual GET to /operations/id returns a JSON response like this:

{

  "id": 234,

  "status" : "pending",

  "operation" : "operationname"

}

When the QSM starts executing the asynchronous operation, the status will change to "in progress"

Once it finishes the operation, the status will change to "complete" and any subsequent call to /operations/{id} will result in a redirect to /operations/{id}/result which holds the actual response code and body as if the initial request was synchronous.

The .../result resource will remain available for some amount of time until it expires.

You can even add headers that specify how long it should take before a subsequent call to /operations/{id} should take place. If a client REST library has automatic redirection activated and is capable of interpreting this header value, you can create some sort of automatic polling mechanism.

As an alternative method, you could use webhooks but this is more server-server communication. It's hard to get this working in a browser-based server to client environment.

Another alternative is SSE, which can be implemented by just keeping the request 'open', and "pushing" intermediate results. But this has to adhere to a specific protocol which is quite limited in its use.

The benefit is that most browsers natively support this so that it behaves nicely in server to client environments.