Overview

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:

Attributes	Type	Description
`op_id`	Number	Unique identifier of the operation
`method`	String	Type of operation: add, upd, del, or multiple
`resource`	String	Resource being operated on (e.g., images)
`num_total`	Number	Total number of items in the operation
`num_good`	Number	Number of items successfully processed
`num_bad`	Number	Number of items that failed to process
`is_started`	Boolean	Whether the operation has started execution
`all_good`	Boolean	Whether all items were successfully processed
`do_wait`	Boolean	Whether the operation was executed in synchronous mode
`do_urgent`	Boolean	Whether the operation was prioritized in the queue
`do_strict`	Boolean	Whether strict mode was enabled for the operation
`idle_ms`	Number	Time in milliseconds the operation waited before starting
`exec_ms`	Number	Time in milliseconds the operation took to execute
`created_at`	String	Timestamp when the operation was created
`started_at`	String	Timestamp when the operation started execution
`finished_at`	String	Timestamp when the operation finished
`errors`	Array	List 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>'

Get Started

Manage your content

Monitoring your operations

Search

Structure of an Operation

Operations Endpoints

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

Request Example

Response

Receive operation status (Response code: 200)

See all operations (`GET /ops`)

Request Example

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

Request Example

​Structure of an Operation

​Operations Endpoints

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

​Request Example

​Response

Receive operation status (Response code: 200)

​See all operations (GET /ops)

​Request Example

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

​Request Example

Structure of an Operation

Operations Endpoints

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

Request Example

Response

See all operations (`GET /ops`)

Request Example

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

Request Example