cloud-sdk-reqwest 0.12.3

Optional provider-neutral reqwest transport boundary for cloud-sdk.
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

<p align="center">
  <b>optional provider-neutral reqwest boundary for cloud-sdk.</b><br>
  Provider crates, explicit API domains, security-first release gates, and transport-free core types.
</p>

<div align="center">
  <a href="https://crates.io/crates/cloud-sdk">cloud-sdk crate</a>
  |
  <a href="https://docs.rs/cloud-sdk-reqwest">Docs.rs</a>
  |
  <a href="https://github.com/valkyoth/cloud-sdk/blob/main/docs/RELEASE_PLAN.md">Release Plan</a>
  |
  <a href="https://github.com/valkyoth/cloud-sdk/blob/main/docs/threat-model.md">Threat Model</a>
  |
  <a href="https://github.com/valkyoth/cloud-sdk/blob/main/SECURITY.md">Security</a>
</div>

<br>

<p align="center">
  <a href="https://github.com/valkyoth/cloud-sdk">
    <img src="https://raw.githubusercontent.com/valkyoth/cloud-sdk/main/.github/images/cloud-sdk.webp" alt="cloud-sdk Rust crate overview">
  </a>
</p>

# cloud-sdk-reqwest

Optional provider-neutral transport-adapter boundary for the main
[`cloud-sdk`](https://github.com/valkyoth/cloud-sdk) workspace and
[`cloud-sdk`](https://crates.io/crates/cloud-sdk) crate.

This crate exists so one future reviewed reqwest adapter can serve every cloud
provider without adding transport dependencies to provider crates. It
intentionally does not depend on `reqwest` yet.

Most users should start with:

```toml
[dependencies]
cloud-sdk = "0.15.0"
```

Use this crate only when the release notes say a transport adapter has been
admitted.

## Current Example

```rust
use cloud_sdk_reqwest::ReqwestAdapterStatus;

assert_eq!(
    ReqwestAdapterStatus::DependencyNotAdmitted,
    ReqwestAdapterStatus::DependencyNotAdmitted,
);
```

## Admission Requirements

Before a real reqwest dependency is admitted, the workspace must review:

- HTTP client version, license, features, and maintenance status;
- TLS policy;
- timeout and retry behavior;
- authentication header redaction;
- authority-preserving base URL and origin-form target composition without
  scheme-relative `//` replacement or generic `Url::join` ambiguity;
- final outbound scheme, host, and port verification before attaching an
  authentication header;
- default feature impact;
- mock and live-test strategy.

Provider crates retain ownership of authentication, base URLs, request models,
response interpretation, and provider-specific errors. This crate must not
branch on provider names.