ISO 20078-2:2019 Road vehicles – Extended vehicle (ExVe) web services – Part 2: Access.
This document defines how to access Resources on a Web services interface of an Offering Party using the Hypertext Transfer Protocol Secure (HTTPS). For such an access, the Representational State Transfer (REST) architectural pattern is chosen as a common way to format Resource paths. Some specific extensions to this pattern are defined to allow for asynchronous Resource requests, such as, for example, forcing readouts of data from a connected vehicle.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 20078-1:2019, Road vehicles — Extended vehicle (ExVe) web services — Part 1: Content ISO 20078-3, Road vehicles — Extended vehicle (ExVe) web services — Part 3: Security
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 20078-1 apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso,org/obp
— IEC Electropedia: available at http://www.eIectropedia.org/
3.2 Abbreviated terms
For the purposes of this document, the abbreviated terms given in ISO 20078-1 apply.
4 Representational State Transfer based Interface
4.1 General
The following defines the requirements on a Representational State Transfer (REST)LJ based web service interface using Hypertext Transfer Protocol Secure (HTTPS)[1i[Zi[ai based on Transport Layer Security (TLS) to give the Accessing Party secure Access to Resources provided by the Offering Party.
4.10 Error and Information Messaging
Synchronous and asynchronous REST interactions can tail due to various reasons. To enable the Accessing Party to narrow down the cause, the Offering Party provides suitable error messages. An error consists of an Id (exveErrorld) and a short human readable statement (exveErrorMsg).
To avoid confusion, it should be recognized that depending on the interact ion pattern, error messaging can be included in unsuccessful requests (e.g., HTTP 4xx) but can also he involved in some HTTP 200 transmissions.
EXAMPLE 1 If in an asynchronous interaction the request fails after some time.
For successful and unsuccessful interactions, the Offering Party can provide additional information with a ‘note’ statement (exveNote).ISO 20078-2 pdf download.