Asynchronous Status Check URLs

[MarkDWilliams]

It would be helpful to the ARS' overall performance to move towards an asynchronous model. However, asynchronous endpoints have some problems of their own. Primarily, it is not currently possible for the ARS to distinguish between a very long running query and one which has failed without returning an error to us. This leads to situations in which a query is marked as "Running" indefinitely. We are currently working on a flat timeout for these, but ultimately it would be better to have an endpoint for each service where the ARS can check the status of a pending async query to know whether we should mark the query as being in Error or if it is genuinely still running.

[tokebe]

As an example, BTE currently returns as the JSON body in its initial response to an async query:

{
  "id": "rXEOAosN3L",
  "url": "http://bte.transltr.io/v1/check_query_status/rXEOAosN3L"
}

This returned URL can then be directly queried to check the status of the async query, returning this format:

{
  "id": "rXEOAosN3L", 
  "state": "waiting | in progress | completed | failed", 
  "returnvalue": {
    "status": 200,
    "callback": "Callback url was not provided | Data sent to callback_url",
    "response": {<TRAPI response>},
  }, 
  "progress": 0 
}

[edeutsch]

looks like a great suggestion. What is:

  "progress": 0 

?

[tokebe]

Currently unused due to lack of demand, however our infrastructure supports updating a progress level for a given query during execution.

[edeutsch]

Please review the current proposal:
NCATSTranslator/ReasonerAPI#395