fakecloud_iotwireless/
lib.rs

1//! AWS IoT Wireless (`iotwireless`) restJson1 control-plane service for
2//! fakecloud.
3//!
4//! The full 112-operation AWS IoT Wireless Smithy model (SDK id `IoT Wireless`,
5//! SigV4 signing name `iotwireless`, endpoint prefix `api.iotwireless`). Every
6//! operation is a RESTful `<METHOD> <@http URI>` route with path labels (e.g.
7//! `POST /destinations`, `GET /wireless-devices/{Identifier}`,
8//! `PATCH /fuota-tasks/{Id}`, `DELETE /multicast-groups/{Id}`) so requests are
9//! routed by their HTTP method + `@http` URI template. The route table,
10//! per-operation HTTP bindings, model-derived input constraints, and output
11//! member shapes are all generated from the Smithy model (see `src/generated.rs`,
12//! produced by `scripts/generate-iotwireless-tables.py`).
13//!
14//! **What is real.** Destinations, device profiles, service profiles, FUOTA
15//! tasks, multicast groups, wireless devices, wireless gateways, network-analyzer
16//! configurations, wireless-gateway task definitions, position configurations,
17//! and every other modelled named resource mint proper ARNs / ids, persist
18//! their attributes, and echo them back on read / list with round-tripping
19//! pagination tokens. Unlike AWS IoT Core, IoT Wireless models a create as a
20//! collection `POST` with the identifier in the response, so families whose
21//! create output carries an `Id` mint a UUID-shaped id while the two
22//! name-addressed families (destinations, network-analyzer configurations) key
23//! off the required body `Name`. Tags are ARN-keyed; resource positions store a
24//! raw GeoJSON `@httpPayload` blob per resource. State is account-partitioned
25//! and persisted across restarts. Input validation is model-derived: required
26//! members (including required `@httpPayload`), string `@length`, numeric
27//! `@range`, and `@enum` constraints are enforced with IoT Wireless's declared
28//! exceptions (`ValidationException`, `ResourceNotFoundException`,
29//! `ConflictException`, ...).
30//!
31//! **Honest emulation choices (documented, not stubbed):**
32//! * There is no live LoRaWAN / Sidewalk radio plane. The control plane is
33//!   fully real and persisted, but no device ever transmits, no downlink is
34//!   delivered (`SendDataToWirelessDevice` / `SendDataToMulticastGroup`), no
35//!   FUOTA firmware image is fragmented, and no gateway task runs. Association
36//!   and session operations are accepted and (where addressed by a stored
37//!   resource) persisted, but drive no radio behaviour.
38//! * `UpdateWirelessDevice` is paired by the conformance round-trip heuristic
39//!   with `GetWirelessDeviceImportTask`; that read falls back to the
40//!   wireless-device store so the cross-resource pairing resolves.
41
42pub mod generated;
43pub mod persistence;
44pub mod service;
45pub mod state;
46pub mod validate;
47
48pub use service::{IotWirelessService, IOTWIRELESS_ACTIONS};
49pub use state::{
50    IotWirelessData, IotWirelessSnapshot, SharedIotWirelessState,
51    IOTWIRELESS_SNAPSHOT_SCHEMA_VERSION,
52};
fakecloud_iotwireless/lib.rs

fakecloud_iotwireless/
lib.rs
