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}