ISO 20078-2:2021
(Main)Road vehicles — Extended vehicle (ExVe) web services — Part 2: Access
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). Resources can be accessed through request/reply and/or requested to be pushed. The Representational State Transfer (REST) architectural pattern is chosen as a common way to format resource paths both for request/reply and push. 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.
Véhicules routiers — Web services du véhicule étendu (ExVe) — Partie 2: Accès
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 20078-2
Second edition
2021-11
Road vehicles — Extended vehicle
(ExVe) web services —
Part 2:
Access
Véhicules routiers — Web services du véhicule étendu (ExVe) —
Partie 2: Accès
Reference number
© ISO 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .iv
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 1
3.1 Terms and definitions . 1
3.2 Abbreviated terms . 1
4 Representational state transfer-based interface . 1
4.1 General . 1
4.1.1 Introduction . 1
4.1.2 Request/reply . 2
4.1.3 Push. 2
4.1.4 Push with subsequent request/reply. 4
4.1.5 Requirements . 6
4.2 Resources . 7
4.3 Subscription profiles . 11
4.4 HTTP header fields . 20
4.5 Media types . 21
4.6 Resource versioning . 21
4.7 Resources and web services . 22
4.7.1 General .22
4.7.2 Examples . 22
4.8 Rate limits . 23
4.9 HTTP methods . 24
4.10 HTTP response status codes .25
4.11 Error messaging . 26
4.12 Interaction pattern .29
4.12.1 Asynchronous .29
4.13 Resource discovery. 33
4.14 Capability discovery .34
5 Container management API .35
5.1 General . 35
5.2 Container management operations . 35
Annex A (informative) Container management API specification .45
Annex B (normative) Container management OpenAPI specification .64
Annex C (normative) OpenAPI specification for container push notifications .65
Bibliography .66
iii
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 31,
Data communication.
This second edition cancels and replaces the first edition (ISO 20078-2:2019), which has been
technically revised.
The main changes are as follows:
— added definition of a push method, allowing the offering party to push resources to the accessing
party according to subscription;
— added definition of reusable subscription profiles, used to store URI locations and authorization
information from the accessing party and used by offering party to push subscribed resources;
— defined requirements for container management API;
— added Annex A and digital Annex B describing container management API;
— revised error format;
— redefined resource versioning.
A list of all parts in the ISO 20078 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
iv
INTERNATIONAL STANDARD ISO 20078-2:2021(E)
Road vehicles — Extended vehicle (ExVe) web services —
Part 2:
Access
1 Scope
This document defines how to access resources on a web-services interface of an offering party using
the Hypertext Transfer Protocol Secure (HTTPS). Resources can be accessed through request/reply
and/or requested to be pushed.
The Representational State Transfer (REST) architectural pattern is chosen as a common way to format
resource paths both for request/reply and push. 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, Road vehicles — Extended vehicle (ExVe) web services — Part 1: Content and definitions
ISO 8601 (all parts), Date and time — Representations for information interchange
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 https:// www .electropedia .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
4.1.1 Introduction
There are three different ways to access resources for the accessing party, request/reply, push, and
push with a subsequent request/reply. Request/reply is the recommended method, but push can be
used when needed. In most cases only one method is used for a particular resource, but sometimes both
request/reply and push are needed. Latency, message size and frequency are examples of requirements
to consider when selecting between request/reply, push, and push with subsequent request/reply.
4.1.2 Request/reply
Figure 1 shows an example of request/reply sequence, where the accessing party requests a resource
using HTTP GET and the offering party returns it in the payload.
Figure 1 — Request/reply example
4.1.3 Push
Figure 2 shows an example of push sequence, where the accessing party initiates a push of a resource
using HTTP POST. The offering party confirms the subscription and starts to push the resource using
HTTP POST. Figure 2 shows an example where the push is done two times.
Figure 2 — Push example
Figure 3 shows an example of push sequence, where there is no explicit initiation of the push from the
accessing party. It is instead initiated by for instance rules or configuration at the offering party. It is
outside the scope of this document to describe how this is agreed between the accessing party and the
offering party.
Figure 3 — Push example without explicit initiation
4.1.4 Push with subsequent request/reply
Figure 4 shows an example of push with subsequent request/reply, where the accessing party initiates
a push of a resource using HTTP POST. The offering party confirms the subscription and starts to push
the resource reference using H
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.