Struct SenderEndpoint 

pub struct SenderEndpoint { /* private fields */ }

Available on crate feature transport only.

URLs on a module’s Sender interface: the data owner’s own objects.

A Sender interface is addressed by object id alone, because the owner is the party being called.

Spec: 2.3.0 §mod_locations_cpo_interface and the equivalent section of each module

Implementations

impl SenderEndpoint

pub fn new(base: Url) -> Self

Wraps a discovered Sender endpoint URL.

pub const fn base(&self) -> &Url

The base URL as discovered.

pub fn list(&self, query: &PageQuery) -> Url

GET {base}?[date_from]&[date_to]&[offset]&[limit] — the paginated list.

pub fn object(&self, id: &str) -> Url

GET {base}/{id} — one object.

pub fn location( &self, location_id: &str, evse_uid: Option<&str>, connector_id: Option<&str>, ) -> Url

GET {locations}/{location_id}[/{evse_uid}[/{connector_id}]].

Spec: 2.3.0 §mod_locations_get_object_request_parameters

pub fn token_authorize(&self, token_uid: &str, token_type: Option<&str>) -> Url

POST {tokens}/{token_uid}/authorize[?type={type}] — real-time authorization.

Spec: 2.3.0 §mod_tokens_real-time_authorization

pub fn charging_preferences(&self, session_id: &str) -> Url

PUT {sessions}/{session_id}/charging_preferences.

Spec: 2.3.0 §mod_sessions_set_charging_preferences

pub fn command(&self, command: &str) -> Url

POST {commands}/{command} — a command request on the Receiver’s Sender-side endpoint.

Spec: 2.3.0 §mod_commands_commands_module

pub fn payments_terminals(&self) -> Self

The Payments terminals sub-interface, {payments}/terminals.

Spec gap: one ModuleID, two endpoint URLs

The Payments chapter declares “Module Identifier: payments” and then addresses its two interfaces through two different variables, {payments_terminals_endpoint_url} and {payments_financial_advice_confirmation_endpoint_url}. Version discovery cannot express that: an Endpoint is keyed by identifier and role, so one module and one interface role has exactly one URL. A PTP that advertised both would have to publish two payments/SENDER endpoints, and a client reading them would have no way to tell which was which.

The reading this crate takes — and which the specification’s own examples support, since they are …/payments/terminals/ and …/payments/financial-advice-confirmations/ — is that the discovered payments endpoint is the base the two hang off. This has been reported upstream; until it is resolved, SenderEndpoint::payments_terminals and SenderEndpoint::payments_financial_advice_confirmations also tolerate a peer that advertised one of the sub-paths directly, so either reading interoperates.

pub fn payments_financial_advice_confirmations(&self) -> Self

The Payments financial advice confirmations sub-interface. See payments_terminals for why this is derived rather than discovered.

pub fn terminal(&self, terminal_id: &str) -> Url

{payments}/terminals/{terminal_id} — one payment terminal.

Call this on the endpoint from payments_terminals.

pub fn terminal_deactivate(&self, terminal_id: &str) -> Url

POST {payments}/terminals/{terminal_id}/deactivate.

pub fn terminal_activate(&self) -> Url

POST {payments}/terminals/activate.

Trait Implementations

impl Clone for SenderEndpoint

fn clone(&self) -> SenderEndpoint

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for SenderEndpoint

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Eq for SenderEndpoint

impl PartialEq for SenderEndpoint

fn eq(&self, other: &SenderEndpoint) -> bool

Equality operator ==.

fn ne(&self, other: &Rhs) -> bool

Inequality operator !=.

impl StructuralPartialEq for SenderEndpoint