ocpi/
versions_module.rs

1//!
2//! # 6. Versions module
3//! Type: Configuration Module
4//! This is the required base module of OCPI.
5//! This module is the starting point for any OCPI connection.
6//! Via this module, clients can learn which versions of OCPI a server supports,
7//! and which modules it supports for each of the versions.
8//!
9use crate::{types, CommandsHandler, Context, Result, VersionsStore};
10use async_trait::async_trait;
11
12#[async_trait]
13pub trait VersionsModule {
14    /// # 6.1. Version information endpoint
15    /// This endpoint lists all the available OCPI versions and the corresponding
16    /// URLs to where version specific details such as the
17    /// supported endpoints can be found.
18    /// Endpoint structure definition:
19    ///
20    /// No structure defined. This is open for every party to define themselves.
21    /// Examples:
22    /// https://www.server.com/ocpi/cpo/versions
23    /// https://www.server.com/ocpi/emsp/versions
24    /// https://ocpi.server.com/versions
25    /// The exact URL to the implemented version endpoint should be given (offline)
26    /// to parties that want to communicate with your OCPI implementation.
27    /// Both, CPOs and eMSPs MUST implement such a version endpoint.
28    async fn versions_get(&self, ctx: Context) -> Result<Vec<types::Version>>;
29
30    /// 6.2. Version details endpoint
31    ///
32    /// Via the version details, the parties can exchange which modules are implemented
33    /// for a specific version of OCPI, which interface role is implemented,
34    /// and what the endpoint URL is for this interface.
35    /// Parties that are both CPO and eMSP (or a Hub) can implement one
36    /// version endpoint that covers both roles.
37    /// With the information that is available in the version details,
38    /// parties don’t need to implement a separate endpoint per role (CPO or eMSP) anymore.
39    /// In practice this means that when a company is both a CPO and an eMSP and it connects
40    /// to another party that implements both interfaces, only one OCPI connection is needed.
41    ///
42    /// __NOTE__
43    /// OCPI 2.2 introduces the role field in the version details.
44    /// Older versions of OCPI do not support this.
45    ///
46    /// Endpoint structure definition:
47    /// No structure defined. This is open for every party to define themselves.
48    /// __Examples__:
49    /// `https://www.server.com/ocpi/cpo/2.2`
50    /// `https://www.server.com/ocpi/emsp/2.2`
51    /// `https://ocpi.server.com/2.2/details`
52    ///
53    /// This endpoint lists the supported endpoints and their URLs for a specific OCPI version.
54    /// To notify the other party that the list of endpoints of your current version has changed,
55    /// you can send a PUT request to the corresponding credentials endpoint
56    /// (see the credentials chapter).
57    ///
58    /// Both the CPO and the eMSP MUST implement this endpoint.
59    async fn versions_get_details(
60        &self,
61        ctx: Context,
62        version_number: types::VersionNumber,
63    ) -> Result<Option<types::VersionDetails>>;
64}
65
66#[async_trait]
67impl<DB, CH> VersionsModule for crate::Cpo<DB, CH>
68where
69    DB: crate::Store + VersionsStore,
70    CH: CommandsHandler,
71{
72    async fn versions_get(&self, ctx: Context) -> Result<Vec<types::Version>> {
73        self.db.get_authorized(ctx.credentials_token).await?;
74
75        self.db.versions_get_all().await
76    }
77
78    async fn versions_get_details(
79        &self,
80        ctx: Context,
81        version_number: types::VersionNumber,
82    ) -> Result<Option<types::VersionDetails>> {
83        self.db.get_authorized(ctx.credentials_token).await?;
84
85        self.db.versions_get_details(version_number).await
86    }
87}
ocpi/versions_module.rs

ocpi/
versions_module.rs
