High-level API
Overview
This layer provides high-level APIs, allowing easier access to server operations. API includes Repositories and Entities. Repositories provide management operations for Entities. Entities represent objects on the server (e.g. projects, tasks, jobs etc) and simplify interaction with them. The key difference from the low-level API is that operations on this layer are not limited by a single server request per operation and encapsulate low-level request machinery behind a high-level object-oriented API.
The code of this component is located in the cvat_sdk.core
package.
Example
Client
The cvat_sdk.core.client.Client
class provides session management, implements
authentication operations and simplifies access to server APIs.
It is the starting point for using CVAT SDK.
A Client
instance allows you to:
- configure connection options with the
Config
class - check server API compatibility with the current SDK version
- deduce server connection scheme (
https
orhttp
) automatically - manage user session with the
login()
,logout()
and other methods - obtain Repository objects with the
users
,tasks
,jobs
and other members - reach to lower-level APIs with the corresponding members
An instance of Client
can be created directly by calling the class constructor
or with the utility function cvat_sdk.core.client.make_client()
which can handle
some configuration for you. A Client
can be configured with
the cvat_sdk.core.client.Config
class instance. A Config
object can be passed to
the Client
constructor and then it will be available in the Client.config
field.
The Client
class implements the context manager protocol.
When the context is closed, the session is finished, and the user is logged out
automatically. Otherwise, these actions can be done with the close()
and logout()
methods.
You can create and start using a Client
instance this way:
The make_client()
function handles configuration and object creation for you.
It also allows to authenticate right after the object is created.
If you need to configure Client
parameters, you can do this:
You can specify server address both with and without the scheme. If the scheme is omitted, it will be deduced automatically.
The checks are performed in the following order:
https
(with the default port 8080),http
(with the default port 80). In some cases it may lead to incorrect results - e.g. you have 2 servers running on the same host at default ports. In such cases just specify the schema manually:https://localhost
.
When the server is located, its version is checked. If an unsupported version is found,
an error can be raised or suppressed (controlled by config.allow_unsupported_server
).
If the error is suppressed, some SDK functions may not work as expected with this server.
By default, a warning is raised and the error is suppressed.
Users and organizations
All Client
operations rely on the server API and depend on the current user
rights. This affects the set of available APIs, objects and actions. For example, a regular user
can only see and modify their tasks and jobs, while an admin user can see all the tasks etc.
Operations are also affected by the current organization context,
which can be set with the organization_slug
property of Client
instances.
The organization context affects which entities are visible,
and where new entities are created.
Set organization_slug
to an organization’s slug (short name)
to make subsequent operations work in the context of that organization:
You can also set organization_slug
to an empty string
to work in the context of the user’s personal workspace.
By default, it is set to None
,
which means that both personal and organizational entities are visible,
while new entities are created in the personal workspace.
To temporarily set the organization slug, use the organization_context
function:
Entities and Repositories
Entities represent objects on the server. They provide read access to object fields and implement additional relevant operations, including both the general Read-Update-Delete and object-specific ones. The set of available general operations depends on the object type.
Repositories provide management operations for corresponding Entities. You don’t
need to create Repository objects manually. To obtain a Repository object, use the
corresponding Client
instance member:
An Entity can be created on the server with the corresponding Repository method create()
:
We can retrieve server objects using the retrieve()
and list()
methods of the Repository:
After calling these functions, we obtain local objects representing their server counterparts.
Object fields can be updated with the update()
method. Note that the set of fields that can be
modified can be different from what is available for reading.
The server object will be updated and the local object will reflect the latest object state after calling this operation.
Note that local objects may fall out of sync with their server counterparts for different reasons.
If you need to update the local object with the latest server state, use the fetch()
method:
Finally, if you need to remove the object from the server, you can use the remove()
method.
The server object will be removed, but the local copy of the object will remain untouched.
Repositories can also provide group operations over entities. For instance, you can retrieve
all available objects using the list()
Repository method. The list of available
Entity and Repository operations depends on the object type.
You can learn more about entity members and how model parameters are passed to functions here.
The implementation for these components is located in cvat_sdk.core.proxies
.