From 5e8757ec8057aaf22af0c4edccd8ec2cf6e1decb Mon Sep 17 00:00:00 2001 From: Todd Martin Date: Wed, 17 Dec 2025 09:19:35 -0500 Subject: [PATCH 1/3] Remove bitwarden-core docs to move to crate. --- docs/architecture/sdk/internal/index.md | 50 ++----------------------- 1 file changed, 3 insertions(+), 47 deletions(-) diff --git a/docs/architecture/sdk/internal/index.md b/docs/architecture/sdk/internal/index.md index afa2eba06..42854e161 100644 --- a/docs/architecture/sdk/internal/index.md +++ b/docs/architecture/sdk/internal/index.md @@ -126,12 +126,9 @@ Password Manager, or Secrets Manager, into a single easy-to-use crate for that p ### Core and Utility -The `bitwarden-core` crate contains the underlying functionality of the SDK. This includes a -[`Client` struct](#client-struct). - -There are a number of utility crates that provide a very narrow scope of functionality and do not -necessarily correspond to a single domain, or may be shared across multiple domains. Examples -include UUID handling and cryptographic primitives. +The `bitwarden-core` crate contains the core runtime of the SDK. See the +[crate documentation](https://github.com/bitwarden/sdk-internal/tree/main/crates/bitwarden-core) for +more details. ### Features and Domains @@ -139,47 +136,6 @@ Feature and domain crates constitute the application business logic. Feature cra `bitwarden-core` and provide extensions to the Client struct to implement specific domains. These crates are usually owned and maintained by individual teams. -## Client Struct - -The `Client` struct is the main entry point for the SDK and represents a single account instance. -Any action that needs to be performed on the account is generally done through the `Client` struct. -This allows the internals to be hidden from the consumer and provides a clear API. - -We can extend the `Client` struct using extension traits in feature crates. This allow the -underlying implementation to be internal to the crate with only the public API exposed through the -`Client` struct. Below is an example of a generator extension for the `Client` struct. - -```rust -/// Generator extension for the Client struct -#[cfg_attr(feature = "wasm", wasm_bindgen)] -pub struct GeneratorClient { - client: Client, -} - -#[cfg_attr(feature = "wasm", wasm_bindgen)] -impl GeneratorClient { - fn new(client: Client) -> Self { - Self { client } - } - - /// Generates a password based on the provided request. - pub fn password(&self, input: PasswordGeneratorRequest) -> Result { - password(input) - } -} - -/// Extension which exposes `generator` method on the `Client` struct. -pub trait GeneratorClientExt { - fn generator(&self) -> GeneratorClient; -} - -impl GeneratorClientExt for Client { - fn generator(&self) -> GeneratorClient { - GeneratorClient::new(self.clone()) - } -} -``` - ## Language bindings The internal SDK supports mobile and web platforms and uses UniFFI and `wasm-bindgen` to generate From 7df23a949c72b5b4cc4cdfc4e9f50f7d6eb1482c Mon Sep 17 00:00:00 2001 From: Todd Martin Date: Wed, 17 Dec 2025 21:10:45 -0500 Subject: [PATCH 2/3] Remove server bindings docs. --- docs/architecture/sdk/server-bindings.md | 64 ------------------------ 1 file changed, 64 deletions(-) delete mode 100644 docs/architecture/sdk/server-bindings.md diff --git a/docs/architecture/sdk/server-bindings.md b/docs/architecture/sdk/server-bindings.md deleted file mode 100644 index 9a1aecf0a..000000000 --- a/docs/architecture/sdk/server-bindings.md +++ /dev/null @@ -1,64 +0,0 @@ -# Server Bindings - -The SDK currently uses auto-generated bindings for the server. The bindings are generated using the -[`openapi-generator`][openapi] to generate the Rust bindings from the server OpenAPI specifications. -These bindings are regularly updated to ensure they stay in sync with the server. - -The bindings are exposed as multiple crates, one for each backend service: - -- `bitwarden-api-api`: For the `Api` service that contains most of the server side functionality. -- `bitwarden-api-identity`: For the `Identity` service that is used for authentication. - -When performing any API calls the goal is to use the generated bindings as much as possible. This -ensures any changes to the server are accurately reflected in the SDK. The generated bindings are -stateless, and always expects to be provided a `Configuration` instance. The SDK exposes these under -the `get_api_configurations` function on the `Client` struct. `get_api_configurations` also -refreshes the authentication token if required. - -```rust -// Example API call -let config: &ApiConfigurations = client.get_api_configurations().await; -let response: SyncResponseModel = - bitwarden_api_api::apis::sync_api::sync_get(&config.api, exclude_subdomains).await?; -``` - -You _should not_ expose the request and response models of the auto generated bindings and _should_ -instead define and use your own models. This ensures the server request / response models are -decoupled from the SDK models, which allows for easier changes in the future without breaking -backwards compatibility. - -We recommend using either the [`From`][from] or [`TryFrom`][tryfrom] [conversion traits][conversion] -depending on if the conversion requires error handling or not. Below are two examples of how this -can be done: - -```rust -impl TryFrom for LoginUri { - type Error = Error; - - fn try_from(uri: bitwarden_api_api::models::CipherLoginUriModel) -> Result { - Ok(Self { - uri: EncString::try_from_optional(uri.uri)?, - r#match: uri.r#match.map(|m| m.into()), - uri_checksum: EncString::try_from_optional(uri.uri_checksum)?, - }) - } -} - -impl From for UriMatchType { - fn from(value: bitwarden_api_api::models::UriMatchType) -> Self { - match value { - bitwarden_api_api::models::UriMatchType::Domain => Self::Domain, - bitwarden_api_api::models::UriMatchType::Host => Self::Host, - bitwarden_api_api::models::UriMatchType::StartsWith => Self::StartsWith, - bitwarden_api_api::models::UriMatchType::Exact => Self::Exact, - bitwarden_api_api::models::UriMatchType::RegularExpression => Self::RegularExpression, - bitwarden_api_api::models::UriMatchType::Never => Self::Never, - } - } -} -``` - -[openapi]: https://github.com/OpenAPITools/openapi-generator -[from]: https://doc.rust-lang.org/std/convert/trait.From.html -[tryfrom]: https://doc.rust-lang.org/std/convert/trait.TryFrom.html -[conversion]: https://doc.rust-lang.org/std/convert/index.html From d2030ab126705dd280df9bfa565074e36146aaa1 Mon Sep 17 00:00:00 2001 From: Todd Martin Date: Wed, 17 Dec 2025 21:18:32 -0500 Subject: [PATCH 3/3] Removed link to page. --- docs/architecture/sdk/data-models.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/docs/architecture/sdk/data-models.md b/docs/architecture/sdk/data-models.md index 16ac9644f..b8248f530 100644 --- a/docs/architecture/sdk/data-models.md +++ b/docs/architecture/sdk/data-models.md @@ -22,8 +22,7 @@ We can generally group the public models into the following categories: The SDK also maintains internal models: -- **API models**: [Auto-generated models](./server-bindings.md) that are used to interact with the - server. +- **API models**: Auto-generated models that are used to interact with the server. - **Domain models**: General data models used to represent a specific concern in the SDK. For example, `Cipher`, `Folder`, etc. - **DTO**: Data Transfer Objects are used to transfer data between layers of the SDK. They are