Currently long running commands started via the HTTP API would time out and the user can possibly not determine if the command just took too long for the network time-out or something server-side went wrong. So if the user is aware that a command will take long they should be able to mark such a command so the server returns an Accepted HTTP status (202) and executes the command without reporting its result.
The proposed parameter for the POST request body is awaitResponse which is by default true.
For example (using an example from the docs):
curl -X POST http://localhost:2480/api/v1/command/school \
-d '{ "language": "sql", "command": "create document type Class", "awaitResponse":false}' \
-H "Content-Type: application/json" \
--user root:arcadedb-password
Would just return status 202. If the command worked has to be checked in the log.
Note: As discussed with @lvca on Discord.
Reactions are currently unavailable
Currently long running commands started via the HTTP API would time out and the user can possibly not determine if the command just took too long for the network time-out or something server-side went wrong. So if the user is aware that a command will take long they should be able to mark such a command so the server returns an Accepted HTTP status (202) and executes the command without reporting its result.
The proposed parameter for the POST request body is awaitResponse which is by default true.
For example (using an example from the docs):
curl -X POST http://localhost:2480/api/v1/command/school \ -d '{ "language": "sql", "command": "create document type Class", "awaitResponse":false}' \ -H "Content-Type: application/json" \ --user root:arcadedb-passwordWould just return status 202. If the command worked has to be checked in the log.
Note: As discussed with @lvca on Discord.