Trait VersionsModule 

pub trait VersionsModule {
    // Required methods
    fn versions_get<'life0, 'async_trait>(
        &'life0 self,
        ctx: Context,
    ) -> Pin<Box<dyn Future<Output = Result<Vec<Version>>> + Send + 'async_trait>>
       where Self: 'async_trait,
             'life0: 'async_trait;
    fn versions_get_details<'life0, 'async_trait>(
        &'life0 self,
        ctx: Context,
        version_number: VersionNumber,
    ) -> Pin<Box<dyn Future<Output = Result<Option<VersionDetails>>> + Send + 'async_trait>>
       where Self: 'async_trait,
             'life0: 'async_trait;
}

Required Methods

fn versions_get<'life0, 'async_trait>( &'life0 self, ctx: Context, ) -> Pin<Box<dyn Future<Output = Result<Vec<Version>>> + Send + 'async_trait>>

where Self: 'async_trait, 'life0: 'async_trait,

6.1. Version information endpoint

This endpoint lists all the available OCPI versions and the corresponding URLs to where version specific details such as the supported endpoints can be found. Endpoint structure definition:

No structure defined. This is open for every party to define themselves. Examples: https://www.server.com/ocpi/cpo/versions https://www.server.com/ocpi/emsp/versions https://ocpi.server.com/versions The exact URL to the implemented version endpoint should be given (offline) to parties that want to communicate with your OCPI implementation. Both, CPOs and eMSPs MUST implement such a version endpoint.

fn versions_get_details<'life0, 'async_trait>( &'life0 self, ctx: Context, version_number: VersionNumber, ) -> Pin<Box<dyn Future<Output = Result<Option<VersionDetails>>> + Send + 'async_trait>>

where Self: 'async_trait, 'life0: 'async_trait,

6.2. Version details endpoint

Via the version details, the parties can exchange which modules are implemented for a specific version of OCPI, which interface role is implemented, and what the endpoint URL is for this interface. Parties that are both CPO and eMSP (or a Hub) can implement one version endpoint that covers both roles. With the information that is available in the version details, parties don’t need to implement a separate endpoint per role (CPO or eMSP) anymore. In practice this means that when a company is both a CPO and an eMSP and it connects to another party that implements both interfaces, only one OCPI connection is needed.

NOTE OCPI 2.2 introduces the role field in the version details. Older versions of OCPI do not support this.

Endpoint structure definition: No structure defined. This is open for every party to define themselves. Examples: https://www.server.com/ocpi/cpo/2.2 https://www.server.com/ocpi/emsp/2.2 https://ocpi.server.com/2.2/details

This endpoint lists the supported endpoints and their URLs for a specific OCPI version. To notify the other party that the list of endpoints of your current version has changed, you can send a PUT request to the corresponding credentials endpoint (see the credentials chapter).

Both the CPO and the eMSP MUST implement this endpoint.

Implementors

impl<DB, CH> VersionsModule for Cpo<DB, CH>

where DB: Store + VersionsStore, CH: CommandsHandler,