vss_client/
types.rs

1/// Request payload to be used for `GetObject` API call to server.
2#[allow(clippy::derive_partial_eq_without_eq)]
3#[derive(Clone, PartialEq, ::prost::Message)]
4pub struct GetObjectRequest {
5	/// `store_id` is a keyspace identifier.
6	/// Ref: <https://en.wikipedia.org/wiki/Keyspace_(distributed_data_store>)
7	/// All APIs operate within a single `store_id`.
8	/// It is up to clients to use single or multiple stores for their use-case.
9	/// This can be used for client-isolation/ rate-limiting / throttling on the server-side.
10	/// Authorization and billing can also be performed at the `store_id` level.
11	#[prost(string, tag = "1")]
12	pub store_id: ::prost::alloc::string::String,
13	/// The key of the value to be fetched.
14	///
15	/// If the specified `key` does not exist, returns `ErrorCode.NO_SUCH_KEY_EXCEPTION` in the
16	/// the `ErrorResponse`.
17	///
18	/// Consistency Guarantee:
19	/// Get(read) operations against a `key` are consistent reads and will reflect all previous writes,
20	/// since Put/Write provides read-after-write and read-after-update consistency guarantees.
21	///
22	/// Read Isolation:
23	/// Get/Read operations against a `key` are ensured to have read-committed isolation.
24	/// Ref: <https://en.wikipedia.org/wiki/Isolation_(database_systems>)#Read_committed
25	#[prost(string, tag = "2")]
26	pub key: ::prost::alloc::string::String,
27}
28/// Server response for `GetObject` API.
29#[allow(clippy::derive_partial_eq_without_eq)]
30#[derive(Clone, PartialEq, ::prost::Message)]
31pub struct GetObjectResponse {
32	/// Fetched `value` and `version` along with the corresponding `key` in the request.
33	#[prost(message, optional, tag = "2")]
34	pub value: ::core::option::Option<KeyValue>,
35}
36/// Request payload to be used for `PutObject` API call to server.
37#[allow(clippy::derive_partial_eq_without_eq)]
38#[derive(Clone, PartialEq, ::prost::Message)]
39pub struct PutObjectRequest {
40	/// `store_id` is a keyspace identifier.
41	/// Ref: <https://en.wikipedia.org/wiki/Keyspace_(distributed_data_store>)
42	/// All APIs operate within a single `store_id`.
43	/// It is up to clients to use single or multiple stores for their use-case.
44	/// This can be used for client-isolation/ rate-limiting / throttling on the server-side.
45	/// Authorization and billing can also be performed at the `store_id` level.
46	#[prost(string, tag = "1")]
47	pub store_id: ::prost::alloc::string::String,
48	/// `global_version` is a sequence-number/version of the whole store. This can be used for versioning
49	/// and ensures that multiple updates in case of multiple devices can only be done linearly, even
50	/// if those updates did not directly conflict with each other based on keys/`transaction_items`.
51	///
52	/// If present, the write will only succeed if the current server-side `global_version` against
53	/// the `store_id` is same as in the request.
54	/// Clients are expected to store (client-side) the global version against `store_id`.
55	/// The request must contain their client-side value of `global_version` if global versioning and
56	/// conflict detection is desired.
57	///
58	/// For the first write of the store, global version should be '0'. If the write succeeds, clients
59	/// must increment their global version (client-side) by 1.
60	/// The server increments `global_version` (server-side) for every successful write, hence this
61	/// client-side increment is required to ensure matching versions. This updated global version
62	/// should be used in subsequent `PutObjectRequest`s for the store.
63	///
64	/// Requests with a conflicting version will fail with `CONFLICT_EXCEPTION` as ErrorCode.
65	#[prost(int64, optional, tag = "2")]
66	pub global_version: ::core::option::Option<i64>,
67	/// Items to be written as a result of this `PutObjectRequest`.
68	///
69	/// In an item, each `key` is supplied with its corresponding `value` and `version`.
70	/// Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
71	/// If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
72	///
73	/// Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
74	/// a database-transaction in an all-or-nothing fashion.
75	/// All Items in a single `PutObjectRequest` must have distinct keys.
76	///
77	/// Key-level versioning (Conditional Write):
78	///    Clients are expected to store a `version` against every `key`.
79	///    The write will succeed if the current DB version against the `key` is the same as in the request.
80	///    When initiating a `PutObjectRequest`, the request should contain their client-side `version`
81	///    for that key-value.
82	///
83	///    For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
84	///    must increment their corresponding key versions (client-side) by 1.
85	///    The server increments key versions (server-side) for every successful write, hence this
86	///    client-side increment is required to ensure matching versions. These updated key versions should
87	///    be used in subsequent `PutObjectRequest`s for the keys.
88	///
89	///    Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
90	///    for conditional writes.
91	///
92	/// Skipping key-level versioning (Non-conditional Write):
93	///    If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
94	///    This will perform a non-conditional write query, after which the `version` against the `key`
95	///    is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
96	///    a non-conditional write or a conditional write with `version` set to `1`.
97	///
98	/// Considerations for transactions:
99	/// Transaction writes of multiple items have a performance overhead, hence it is recommended to use
100	/// them only if required by the client application to ensure logic/code correctness.
101	/// That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
102	/// When a write of multiple unrelated items is desired, it is recommended to use separate
103	/// `PutObjectRequest`s.
104	///
105	/// Consistency guarantee:
106	/// All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
107	/// read-after-update consistency guarantees.
108	#[prost(message, repeated, tag = "3")]
109	pub transaction_items: ::prost::alloc::vec::Vec<KeyValue>,
110	/// Items to be deleted as a result of this `PutObjectRequest`.
111	///
112	/// Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
113	///
114	/// Key-Level Versioning (Conditional Delete):
115	///    The `version` is used to perform a version check before deleting the item.
116	///    The delete will only succeed if the current database version against the `key` is the same as
117	///    the `version` specified in the request.
118	///
119	/// Skipping key-level versioning (Non-conditional Delete):
120	///    If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
121	///    This will perform a non-conditional delete query.
122	///
123	/// Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
124	///    * The requested item does not exist.
125	///    * The requested item does exist but there is a version-number mismatch (in conditional delete)
126	///      with the one in the database.
127	///
128	/// Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
129	/// database transaction in an all-or-nothing fashion.
130	///
131	/// All items within a single `PutObjectRequest` must have distinct keys.
132	#[prost(message, repeated, tag = "4")]
133	pub delete_items: ::prost::alloc::vec::Vec<KeyValue>,
134}
135/// Server response for `PutObject` API.
136#[allow(clippy::derive_partial_eq_without_eq)]
137#[derive(Clone, PartialEq, ::prost::Message)]
138pub struct PutObjectResponse {}
139/// Request payload to be used for `DeleteObject` API call to server.
140#[allow(clippy::derive_partial_eq_without_eq)]
141#[derive(Clone, PartialEq, ::prost::Message)]
142pub struct DeleteObjectRequest {
143	/// `store_id` is a keyspace identifier.
144	/// Ref: <https://en.wikipedia.org/wiki/Keyspace_(distributed_data_store>)
145	/// All APIs operate within a single `store_id`.
146	/// It is up to clients to use single or multiple stores for their use-case.
147	/// This can be used for client-isolation/ rate-limiting / throttling on the server-side.
148	/// Authorization and billing can also be performed at the `store_id` level.
149	#[prost(string, tag = "1")]
150	pub store_id: ::prost::alloc::string::String,
151	/// Item to be deleted as a result of this `DeleteObjectRequest`.
152	///
153	/// An item consists of a `key` and its corresponding `version`.
154	///
155	/// Key-level Versioning (Conditional Delete):
156	///    The item is only deleted if the current database version against the `key` is the same as
157	///    the `version` specified in the request.
158	///
159	/// Skipping key-level versioning (Non-conditional Delete):
160	///    If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
161	///    This will perform a non-conditional delete query.
162	///
163	/// This operation is idempotent, that is, multiple delete calls for the same item will not fail.
164	///
165	/// If the requested item does not exist, this operation will not fail.
166	/// If you wish to perform stricter checks while deleting an item, consider using `PutObject` API.
167	#[prost(message, optional, tag = "2")]
168	pub key_value: ::core::option::Option<KeyValue>,
169}
170/// Server response for `DeleteObject` API.
171#[allow(clippy::derive_partial_eq_without_eq)]
172#[derive(Clone, PartialEq, ::prost::Message)]
173pub struct DeleteObjectResponse {}
174/// Request payload to be used for `ListKeyVersions` API call to server.
175#[allow(clippy::derive_partial_eq_without_eq)]
176#[derive(Clone, PartialEq, ::prost::Message)]
177pub struct ListKeyVersionsRequest {
178	/// `store_id` is a keyspace identifier.
179	/// Ref: <https://en.wikipedia.org/wiki/Keyspace_(distributed_data_store>)
180	/// All APIs operate within a single `store_id`.
181	/// It is up to clients to use single or multiple stores for their use-case.
182	/// This can be used for client-isolation/ rate-limiting / throttling on the server-side.
183	/// Authorization and billing can also be performed at the `store_id` level.
184	#[prost(string, tag = "1")]
185	pub store_id: ::prost::alloc::string::String,
186	/// A `key_prefix` is a string of characters at the beginning of the key. Prefixes can be used as
187	/// a way to organize key-values in a similar way to directories.
188	///
189	/// If `key_prefix` is specified, the response results will be limited to those keys that begin with
190	/// the specified prefix.
191	///
192	/// If no `key_prefix` is specified or it is empty (""), all the keys are eligible to be returned in
193	/// the response.
194	#[prost(string, optional, tag = "2")]
195	pub key_prefix: ::core::option::Option<::prost::alloc::string::String>,
196	/// `page_size` is used by clients to specify the maximum number of results that can be returned by
197	/// the server.
198	/// The server may further constrain the maximum number of results returned in a single page.
199	/// If the `page_size` is 0 or not set, the server will decide the number of results to be returned.
200	#[prost(int32, optional, tag = "3")]
201	pub page_size: ::core::option::Option<i32>,
202	/// `page_token` is a pagination token.
203	///
204	/// To query for the first page of `ListKeyVersions`, `page_token` must not be specified.
205	///
206	/// For subsequent pages, use the value that was returned as `next_page_token` in the previous
207	/// page's `ListKeyVersionsResponse`.
208	#[prost(string, optional, tag = "4")]
209	pub page_token: ::core::option::Option<::prost::alloc::string::String>,
210}
211/// Server response for `ListKeyVersions` API.
212#[allow(clippy::derive_partial_eq_without_eq)]
213#[derive(Clone, PartialEq, ::prost::Message)]
214pub struct ListKeyVersionsResponse {
215	/// Fetched keys and versions.
216	/// Even though this API reuses the `KeyValue` struct, the `value` sub-field will not be set by the server.
217	#[prost(message, repeated, tag = "1")]
218	pub key_versions: ::prost::alloc::vec::Vec<KeyValue>,
219	/// `next_page_token` is a pagination token, used to retrieve the next page of results.
220	/// Use this value to query for next-page of paginated `ListKeyVersions` operation, by specifying
221	/// this value as the `page_token` in the next request.
222	///
223	/// If `next_page_token` is empty (""), then the "last page" of results has been processed and
224	/// there is no more data to be retrieved.
225	///
226	/// If `next_page_token` is not empty, it does not necessarily mean that there is more data in the
227	/// result set. The only way to know when you have reached the end of the result set is when
228	/// `next_page_token` is empty.
229	///
230	/// Caution: Clients must not assume a specific number of key_versions to be present in a page for
231	/// paginated response.
232	#[prost(string, optional, tag = "2")]
233	pub next_page_token: ::core::option::Option<::prost::alloc::string::String>,
234	/// `global_version` is a sequence-number/version of the whole store.
235	///
236	/// `global_version` is only returned in response for the first page of the `ListKeyVersionsResponse`
237	/// and is guaranteed to be read before reading any key-versions.
238	///
239	/// In case of refreshing the complete key-version view on the client-side, correct usage for
240	/// the returned `global_version` is as following:
241	///    1. Read `global_version` from the first page of paginated response and save it as local variable.
242	///    2. Update all the `key_versions` on client-side from all the pages of paginated response.
243	///    3. Update `global_version` on client_side from the local variable saved in step-1.
244	/// This ensures that on client-side, all current `key_versions` were stored at `global_version` or later.
245	/// This guarantee is helpful for ensuring the versioning correctness if using the `global_version`
246	/// in `PutObject` API and can help avoid the race conditions related to it.
247	#[prost(int64, optional, tag = "3")]
248	pub global_version: ::core::option::Option<i64>,
249}
250/// When HttpStatusCode is not ok (200), the response `content` contains a serialized `ErrorResponse`
251/// with the relevant `ErrorCode` and `message`
252#[allow(clippy::derive_partial_eq_without_eq)]
253#[derive(Clone, PartialEq, ::prost::Message)]
254pub struct ErrorResponse {
255	/// The error code uniquely identifying an error condition.
256	/// It is meant to be read and understood programmatically by code that detects/handles errors by
257	/// type.
258	#[prost(enumeration = "ErrorCode", tag = "1")]
259	pub error_code: i32,
260	/// The error message containing a generic description of the error condition in English.
261	/// It is intended for a human audience only and should not be parsed to extract any information
262	/// programmatically. Client-side code may use it for logging only.
263	#[prost(string, tag = "2")]
264	pub message: ::prost::alloc::string::String,
265}
266/// Represents a key-value pair to be stored or retrieved.
267#[allow(clippy::derive_partial_eq_without_eq)]
268#[derive(Clone, PartialEq, ::prost::Message)]
269pub struct KeyValue {
270	/// Key against which the value is stored.
271	#[prost(string, tag = "1")]
272	pub key: ::prost::alloc::string::String,
273	/// Version field is used for key-level versioning.
274	/// For first write of key, `version` should be '0'. If the write succeeds, clients must increment
275	/// their corresponding key version (client-side) by 1.
276	/// The server increments key version (server-side) for every successful write, hence this
277	/// client-side increment is required to ensure matching versions. These updated key versions should
278	/// be used in subsequent `PutObjectRequest`s for the keys.
279	#[prost(int64, tag = "2")]
280	pub version: i64,
281	/// Object value in bytes which is stored (in put) and fetched (in get).
282	/// Clients must encrypt the secret contents of this blob client-side before sending it over the
283	/// wire to the server in order to preserve privacy and security.
284	/// Clients may use a `Storable` object, serialize it and set it here.
285	#[prost(bytes = "vec", tag = "3")]
286	pub value: ::prost::alloc::vec::Vec<u8>,
287}
288/// Represents a storable object that can be serialized and stored as `value` in `PutObjectRequest`.
289/// Only provided as a helper object for ease of use by clients.
290/// Clients MUST encrypt the `PlaintextBlob` before using it as `data` in `Storable`.
291/// The server does not use or read anything from `Storable`, Clients may use its fields as
292/// required.
293#[allow(clippy::derive_partial_eq_without_eq)]
294#[derive(Clone, PartialEq, ::prost::Message)]
295pub struct Storable {
296	/// Represents an encrypted and serialized `PlaintextBlob`. MUST encrypt the whole `PlaintextBlob`
297	/// using client-side encryption before setting here.
298	#[prost(bytes = "vec", tag = "1")]
299	pub data: ::prost::alloc::vec::Vec<u8>,
300	/// Represents encryption related metadata
301	#[prost(message, optional, tag = "2")]
302	pub encryption_metadata: ::core::option::Option<EncryptionMetadata>,
303}
304/// Represents encryption related metadata
305#[allow(clippy::derive_partial_eq_without_eq)]
306#[derive(Clone, PartialEq, ::prost::Message)]
307pub struct EncryptionMetadata {
308	/// The encryption algorithm used for encrypting the `PlaintextBlob`.
309	#[prost(string, tag = "1")]
310	pub cipher_format: ::prost::alloc::string::String,
311	/// The nonce used for encryption. Nonce is a random or unique value used to ensure that the same
312	/// plaintext results in different ciphertexts every time it is encrypted.
313	#[prost(bytes = "vec", tag = "2")]
314	pub nonce: ::prost::alloc::vec::Vec<u8>,
315	/// The authentication tag used for encryption. It provides integrity and authenticity assurance
316	/// for the encrypted data.
317	#[prost(bytes = "vec", tag = "3")]
318	pub tag: ::prost::alloc::vec::Vec<u8>,
319}
320/// Represents a data blob, which is encrypted, serialized and later used in `Storable.data`.
321/// Since the whole `Storable.data` is client-side encrypted, the server cannot understand this.
322#[allow(clippy::derive_partial_eq_without_eq)]
323#[derive(Clone, PartialEq, ::prost::Message)]
324pub struct PlaintextBlob {
325	/// The unencrypted value.
326	#[prost(bytes = "vec", tag = "1")]
327	pub value: ::prost::alloc::vec::Vec<u8>,
328	/// The version of the value. Can be used by client to verify version integrity.
329	#[prost(int64, tag = "2")]
330	pub version: i64,
331}
332/// ErrorCodes to be used in `ErrorResponse`
333#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash, PartialOrd, Ord, ::prost::Enumeration)]
334#[repr(i32)]
335pub enum ErrorCode {
336	/// Default protobuf Enum value. Will not be used as `ErrorCode` by server.
337	Unknown = 0,
338	/// Used when the request contains mismatched version (either key or global)
339	/// in `PutObjectRequest`. For more info refer `PutObjectRequest`.
340	ConflictException = 1,
341	/// Used in the following cases:
342	///    - The request was missing a required argument.
343	///    - The specified argument was invalid, incomplete or in the wrong format.
344	///    - The request body of api cannot be deserialized into corresponding protobuf object.
345	InvalidRequestException = 2,
346	/// Used when an internal server error occurred, client is probably at no fault and can safely retry
347	/// this error with exponential backoff.
348	InternalServerException = 3,
349	/// Used when the specified `key` in a `GetObjectRequest` does not exist.
350	NoSuchKeyException = 4,
351	/// Used when authentication fails or in case of an unauthorized request.
352	AuthException = 5,
353}
354impl ErrorCode {
355	/// String value of the enum field names used in the ProtoBuf definition.
356	///
357	/// The values are not transformed in any way and thus are considered stable
358	/// (if the ProtoBuf definition does not change) and safe for programmatic use.
359	pub fn as_str_name(&self) -> &'static str {
360		match self {
361			ErrorCode::Unknown => "UNKNOWN",
362			ErrorCode::ConflictException => "CONFLICT_EXCEPTION",
363			ErrorCode::InvalidRequestException => "INVALID_REQUEST_EXCEPTION",
364			ErrorCode::InternalServerException => "INTERNAL_SERVER_EXCEPTION",
365			ErrorCode::NoSuchKeyException => "NO_SUCH_KEY_EXCEPTION",
366			ErrorCode::AuthException => "AUTH_EXCEPTION",
367		}
368	}
369	/// Creates an enum from field names used in the ProtoBuf definition.
370	pub fn from_str_name(value: &str) -> ::core::option::Option<Self> {
371		match value {
372			"UNKNOWN" => Some(Self::Unknown),
373			"CONFLICT_EXCEPTION" => Some(Self::ConflictException),
374			"INVALID_REQUEST_EXCEPTION" => Some(Self::InvalidRequestException),
375			"INTERNAL_SERVER_EXCEPTION" => Some(Self::InternalServerException),
376			"NO_SUCH_KEY_EXCEPTION" => Some(Self::NoSuchKeyException),
377			"AUTH_EXCEPTION" => Some(Self::AuthException),
378			_ => None,
379		}
380	}
381}