Skip to main content
Operations represent tasks that users can submit to the Wesog system for asynchronous execution—that is, so the client isn’t blocked while the server completes the assigned task. This way of organizing work becomes especially crucial when handling image ingestion, since a given tenant can request the system to upload thousands of different images at once without having to wait or block the system until all uploads are finished.

​
Structure of an Operation

An operation is described by the fields shown in the following table:
AttributesTypeDescription
op_idNumberUnique identifier of the operation
methodStringType of operation: add, upd, del, or multiple
resourceStringResource being operated on (e.g., images)
num_totalNumberTotal number of items in the operation
num_goodNumberNumber of items successfully processed
num_badNumberNumber of items that failed to process
is_startedBooleanWhether the operation has started execution
all_goodBooleanWhether all items were successfully processed
do_waitBooleanWhether the operation was executed in synchronous mode
do_urgentBooleanWhether the operation was prioritized in the queue
do_strictBooleanWhether strict mode was enabled for the operation
idle_msNumberTime in milliseconds the operation waited before starting
exec_msNumberTime in milliseconds the operation took to execute
created_atStringTimestamp when the operation was created
started_atStringTimestamp when the operation started execution
finished_atStringTimestamp when the operation finished
errorsArrayList of errors that occurred during processing
These attributes aren’t provided directly when creating an operation, since there isn’t an endpoint specifically for that. Instead, whenever you call the endpoints for image upload or processing, the Wesog Search system automatically creates these tasks behind the scenes to ensure that a heavy request doesn’t block the entire system, but is interleaved with other clients’ API requests. As operations are primarily used to monitor the progress of tasks, their associated endpoints are designed to:
  • Retrieve all tasks for a given tenant
  • Fetch detailed information about a specific task
  • Cancel a scheduled task
Because these endpoints are not complex enough to require individual sections, they will all be explained together below.

​
Operations Endpoints

​
Check Operation Status (GET /ops/{op_id})

Given a GET /ops/{op_id} request with the header API-Key: <api-key>, you can retrieve the status of a specific operation for a particular tenant.

​
Request Example

curl --request GET \
  --url https://api.wesog.com/ops/{op_id} \
  --header 'API-Key: <api-key>'

​
Response

The response will be a JSON object containing the operation details, including the fields described in the table without the op_id field, which is the one you queried. The errors field will contain any errors that occurred during the operation, if applicable.
Receive operation status (Response code: 200)
Here you can see an example of response JSON object: 
{
  "method": "add",
  "resource": "images",
  "num_total": 100,
  "num_good": 95,
  "num_bad": 5,
  "is_started": true,
  "is_finished": false,
  "all_good": false,
  "do_wait": false,
  "do_urgent": true,
  "do_strict": true,
  "idle_ms": 0,
  "exec_ms": 1500,
  "created_at": "2023-10-01T12:00:00Z",
  "started_at": "2023-10-01T12:00:01Z",
  "finished_at": null,
  "errors": [
    {
      "code": "413",
      "message": "Invalid image format for image123"
    }
  ]
}

​
See all operations (GET /ops)

This endpoint is the simplest, since you only need to send the access API key to the Wesog server; using that, the system can identify the tenant making the request and return all operations they’ve performed. When requesting all operations, no additional parameters beyond the API key in the request header are required, and the server responds with a JSON-formatted list of Operation objects, containing the various parameters shown in the table at the beginning of this section.

​
Request Example

curl --request GET \
  --url https://api.wesog.com/ops \
  --header 'API-Key: <api-key>'

​
Abort current running operation (DELETE /ops/{op_id})

Once a task is started, even if it was indicated to run asynchronously, it may be necessary to abort it. To do this, a DELETE /ops/{op_id} call can be made, sending the header API-Key: <api-key>, and the Wesog server will cancel the operation if it has not yet finished.

​
Request Example

curl --request DELETE \
  --url https://api.wesog.com/ops/{op_id} \
  --header 'API-Key: <api-key>'