EN ISO 19168-1:2021

SLOVENSKI STANDARD
01-september-2021
Geografske informacije - Geoprostorski API za funkcije - 1. del: Osrednji profil (ISO
19168-1:2020)
Geographic information - Geospatial API for features - Part 1: Core (ISO 19168-1:2020)
Information géographique - API géospatiale pour les entités - Partie 1: Profil minimal
(ISO 19168-1:2020)
Ta slovenski standard je istoveten z: EN ISO 19168-1:2021
ICS:
07.040 Astronomija. Geodezija. Astronomy. Geodesy.
Geografija Geography
35.240.70 Uporabniške rešitve IT v IT applications in science
znanosti
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN ISO 19168-1
EUROPEAN STANDARD
NORME EUROPÉENNE
June 2021
EUROPÄISCHE NORM
ICS 35.240.70
English Version
Geographic information - Geospatial API for features - Part
1: Core (ISO 19168-1:2020)
Information géographique - API géospatiale pour les Geoinformation - Raumbezogene API für Features -
entités - Partie 1: Profil minimal (ISO 19168-1:2020) Teil 1: Kern (ISO 19168-1:2020)
This European Standard was approved by CEN on 21 June 2021.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this
European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2021 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN ISO 19168-1:2021 E
worldwide for CEN national Members.

Contents Page
European foreword . 3

European foreword
The text of ISO 19168-1:2020 has been prepared by Technical Committee ISO/TC 211 "Geographic
information/Geomatics” of the International Organization for Standardization (ISO) and has been taken
over as EN ISO 19168-1:2021 by Technical Committee CEN/TC 287 “Geographic Information” the
secretariat of which is held by BSI.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by December 2021, and conflicting national standards
shall be withdrawn at the latest by December 2021.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
According to the CEN-CENELEC Internal Regulations, the national standards organizations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland,
Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of
North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the
United Kingdom.
Endorsement notice
The text of ISO 19168-1:2020 has been approved by CEN as EN ISO 19168-1:2021 without any
modification.
INTERNATIONAL ISO
STANDARD 19168-1
First edition
2020-09
Geographic information — Geospatial
API for features —
Part 1:
Core
Information géographique — API géospatiale pour les entités —
Partie 1: Profil minimal
Reference number
ISO 19168-1:2020(E)
©
ISO 2020
ISO 19168-1:2020(E)
© ISO 2020
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 © ISO 2020 – All rights reserved

ISO 19168-1:2020(E)
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 1
3.1 Abbreviated terms . 2
4 Conformance . 3
5 Conventions . 4
5.1 Identifiers . 4
5.2 Link relations. 4
5.3 Use of HTTPS . 5
5.4 HTTP URIs . 5
5.5 API definition. 5
5.5.1 General remarks . 5
5.5.2 Role of OpenAPI . 5
5.5.3 References to OpenAPI components in normative statements . 6
5.5.4 Paths in OpenAPI definitions . 6
5.5.5 Reusable OpenAPI components . 6
6 Overview . 6
6.1 Design considerations. 6
6.2 Encodings . 7
6.3 Examples . 8
7 Requirements class "Core" . 8
7.1 Overview . 8
7.2 API landing page .10
7.2.1 Operation .10
7.2.2 Response .11
7.2.3 Error situations .11
7.3 API definition.12
7.3.1 Operation .12
7.3.2 Response .12
7.3.3 Error situations .12
7.4 Declaration of conformance classes .12
7.4.1 Operation .12
7.4.2 Response .13
7.4.3 Error situations .13
7.5 HTTP 1.1 .13
7.5.1 HTTP status codes .13
7.6 Unknown or invalid query parameters .14
7.7 Web caching .15
7.8 Support for cross-origin requests.15
7.9 Encodings .15
7.10 String internationalization .16
7.11 Coordinate reference systems .16
7.12 Link headers .17
7.13 Feature collections .17
7.13.1 Operation .17
7.13.2 Response .17
7.13.3 Error situations .22
7.14 Feature collection .22
7.14.1 Operation .22
7.14.2 Response .22
ISO 19168-1:2020(E)
7.14.3 Error situations .22
7.15 Features .23
7.15.1 Operation .23
7.15.2 Parameter limit .23
7.15.3 Parameter bbox .24
7.15.4 Parameter datetime . .25
7.15.5 Parameters for filtering on feature properties .26
7.15.6 Combinations of filter parameters .27
7.15.7 Response .27
7.15.8 Error situations .29
7.16 Feature .30
7.16.1 Operation .30
7.16.2 Response .30
7.16.3 Error situations .30
8 Requirements classes for encodings .31
8.1 Overview .31
8.2 Requirements Class "HTML" .31
8.3 Requirements Class "GeoJSON" .32
8.4 Requirements Class "Geography Markup Language (GML), Simple Features Profile,
Level 0" .33
8.5 Requirements class "Geography Markup Language (GML), Simple Features Profile,
Level 2" .35
9 Requirements class "OpenAPI 3.0" .36
9.1 Basic requirements .36
9.2 Complete definition .36
9.3 Exceptions .37
9.4 Security .37
9.5 Features .37
10 Media types .37
11 Security considerations.38
11.1 General .38
11.2 Multiple access routes .38
11.3 Multiple servers .39
11.4 Path manipulation on GET .39
11.5 Path manipulation on PUT and POST .39
Annex A (normative) Abstract test suite .40
Bibliography .54
iv © ISO 2020 – All rights reserved

ISO 19168-1:2020(E)
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 211, Geographic information/Geomatics.
A list of all parts in the ISO 19168 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.
ISO 19168-1:2020(E)
Introduction
[9]
OGC API standards define modular API building blocks to spatially enable Web APIs in a consistent
manner. The OpenAPI specification is used to define the API building blocks.
The OGC API family of standards is organized by resource type. This document specifies the
fundamental API building blocks for interacting with features. The spatial data community uses the
term 'feature' for things in the real world that are of interest.
For those not familiar with the term 'feature,' the explanations on Spatial Things, Features and
Geometry in the W3C/OGC Spatial Data on the Web Best Practice document provide more detail.
OGC API Features provides API building blocks to create, modify and query features on the Web.
OGC API Features is comprised of multiple parts, each of them a separate standard. This document,
the "Core", specifies the core capabilities and is restricted to fetching features where geometries are
represented in the coordinate reference system, WGS 84, with axis order longitude/latitude. Additional
capabilities that address more advanced needs will be specified in additional parts. Examples include
support for creating and modifying features, more complex data models, richer queries, additional
coordinate reference systems, multiple datasets and collection hierarchies.
By default, every API implementing this document will provide access to a single dataset. Rather than
sharing the data as a complete dataset, the OGC API Features standards offer direct, fine-grained access
to the data at the feature (object) level.
The API building blocks specified in this document are consistent with the architecture of the Web.
In particular, the API design is guided by the IETF HTTP/HTTPS RFCs, the W3C Data on the Web
Best Practices, the W3C/OGC Spatial Data on the Web Best Practices and the emerging OGC Web API
Guidelines. A particular example is the use of the concepts of datasets and dataset distributions as
defined in DCAT and used in schema.org.
This document specifies discovery and query operations that are implemented using the HTTP GET
method. Support for additional methods (in particular POST, PUT, DELETE, PATCH) will be specified in
additional parts.
Discovery operations enable clients to interrogate the API, including the API definition and metadata
about the feature collections provided by the API, to determine the capabilities of the API and retrieve
information about available distributions of the dataset.
Query operations enable clients to retrieve features from the underlying data store based upon simple
selection criteria, defined by the client.
A subset of the OGC API family of standards is expected to be published by ISO. For example, this
document is published by ISO as ISO 19168-1. To reflect that only a subset of the OGC API standards
will be published by ISO and to avoid using organization names in the titles of ISO standards, standards
from the "OGC API" series are published by ISO as "Geospatial API," i.e. the title of this document in OGC
is "OGC API — Features — Part 1: Core" and the title in ISO is "Geographic Information — Geospatial
API for features — Part 1: Core."
For simplicity, this document consistently uses:
— "OGC API" to refer to the family of standards for geospatial Web APIs that in ISO is published as
"Geospatial API;"
— "OGC API - Features" to refer to the multipart standard for features that in ISO is published as
ISO 19168 / "Geographic Information - Geospatial API for features;"
— "OGC API - Features — Part 1: Core" to refer to this document that in ISO is published as ISO 19168-1
/ "Geographic Information - Geospatial API for features — Part 1: Core."
This document defines the resources listed in Table 1. For an overview of the resources, see 7.1.
vi © ISO 2020 – All rights reserved

ISO 19168-1:2020(E)
Table 1 — Overview of resources, applicable HTTP methods and links to the document sections
HTTP
Resource Path method Document reference
Landing page / GET 7.2 API landing page
Conformance /conformance GET 7.4 Declaration of conformance
declaration classes
Feature collections /collections GET 7.13 Feature collections
Feature collection /collections/{collectionId} GET 7.14 Feature collection
Features /collections/{collectionId}/items GET 7.15 Features
Feature /collections/{collectionId}/items/{featureId} GET 7.16 Feature
Implementations of OGC API Features are intended to support two different approaches for how clients
can use the API. For further information, see 6.1.
INTERNATIONAL STANDARD ISO 19168-1:2020(E)
Geographic information — Geospatial API for features —
Part 1:
Core
1 Scope
This document specifies the behaviour of Web APIs that provide access to features in a dataset in a
manner independent of the underlying data store. This document defines discovery and query
operations.
Discovery operations enable clients to interrogate the API, including the API definition and metadata
about the feature collections provided by the API, to determine the capabilities of the API and retrieve
information about available distributions of the dataset.
Query operations enable clients to retrieve features from the underlying data store based upon simple
selection criteria, defined by the client.
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.
Internet Engineering Task Force (IETF), RFC 2818: HTTP Over TLS [online]. Edited by E. Rescorla.
2000 [viewed 2020-03-16]. Available at https:// tools .ietf .org/ rfc/ rfc2818 .txt
Internet Engineering Task Force (IETF), RFC 3339:2002: Date and Time on the Internet:
Timestamps [online]. Edited by G. Klyne, C. Newman. 2002 [viewed 2020-03-16]. Available at https://
tools .ietf .org/ rfc/ rfc3339 .txt
Internet Engineering Task Force (IETF), RFC 7230 to RFC 7235: HTTP/1.1 [online]. Edited by R.
Fielding, J. Reschke, Y. Lafon, M. Nottingham. 2014 [viewed 2020-04-28]. Available at https:// tools
.ietf .org/ rfc/ rfc7230 .txt, https:// tools .ietf .org/ rfc/ rfc7231 .txt, https:// tools .ietf .org/ rfc/ rfc7232 .txt,
https:// tools .ietf .org/ rfc/ rfc7233 .txt, https:// tools .ietf .org/ rfc/ rfc7234 .txt, and https:// tools .ietf .org/
rfc/ rfc7235 .txt
Internet Engineering Task Force (IETF), RFC 8288:2017: Web Linking [online]. Edited by M.
Nottingham. 2017 [viewed 2020-03-16]. Available at https:// tools .ietf .org/ rfc/ rfc8288 .txt
OpenAPI Initiative (OAI), OpenAPI Specification 3.0 [online]. 2020 [viewed 2020-03-16]. The latest
patch version at the time of publication of this standard was 3.0.3, available at http:// spec .openapis
.org/ oas/ v3 .0 .3
3 Terms, definitions and abbreviated terms
For the purposes of this document, the following terms and definitions 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 .electropedia .org/
ISO 19168-1:2020(E)
3.1.1
dataset
collection of data
Note 1 to entry: Published or curated by a single agent, and available for access or download in one or more
formats.
Note 2 to entry: The use of ‘collection’ in the definition from DCAT is broader than the use of the term collection
in this document. See the definition of feature collection (3.1.4).
[8]
[SOURCE: DCAT , 6.6, modified — Definition split into definition and Note 1 to entry; Note 2 to entry
has been added]
3.1.2
distribution
specific representation of a dataset (3.1.1)
EXAMPLE A downloadable file, an RSS feed or an API.
[8]
[SOURCE: DCAT , 6.7, modified — Definition has been shortened]
3.1.3
feature
abstraction of real-world phenomena
Note 1 to entry: The explanations on Spatial Things, Features and Geometry in the W3C/OGC Spatial Data on the
[6]
Web Best Practice document provide more detail.
[SOURCE: ISO 19101-1:2014, 4.1.11, modified — Note 1 to entry has been added]
3.1.4
feature collection
collection
set of features (3.1.3) from a dataset (3.1.1)
3.1.5
Web API
API using an architectural style that is founded on the technologies of the Web
Note 1 to entry: Best Practice 24: Use Web Standards as the foundation of APIs in the W3C Data on the Web Best
[7]
Practices provides more detail.
[7]
[SOURCE: DWBP , 8.10.1, modified — Rephrased for clarity]
3.1 Abbreviated terms
API Application Programming Interface
CORS Cross-Origin Resource Sharing
CRS Coordinate Reference System
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
IANA Internet Assigned Numbers Authority
OGC Open Geospatial Consortium
2 © ISO 2020 – All rights reserved

ISO 19168-1:2020(E)
TRS Temporal Coordinate Reference System
URI Uniform Resource Identifier
YAML YAML Ain’t Markup Language
4 Conformance
This document defines six requirements/conformance classes.
The standardization targets of all conformance classes are "Web APIs."
The main requirements class is:
— Core.
The Core specifies requirements that all Web APIs have to implement.
The Core does not mandate a specific encoding or format for representing features or feature collections.
Four requirements classes depend on the Core and specify representations for these resources in
commonly used encodings for spatial data on the web:
— HTML,
— GeoJSON,
— Geography Markup Language (GML), Simple Features Profile, Level 0, and
— Geography Markup Language (GML), Simple Features Profile, Level 2.
None of these encodings are mandatory and an implementation of the Core may also decide to implement
none of them, but to implement another encoding instead.
That said, the Core requirements class includes recommendations to support, where practical,
HTML and GeoJSON as encodings. Clause 6 (Overview) includes a discussion about the recommended
encodings.
The Core does not mandate any encoding or format for the formal definition of the API either. One
option is the OpenAPI 3.0 specification and a requirements class has been specified for OpenAPI 3.0,
which depends on the Core:
— OpenAPI specification 3.0.
As with the feature encodings, an implementation of the Core requirements class may also decide to
use other API definition representations in addition or instead of an OpenAPI 3.0 definition. Examples
for alternative API definitions: OpenAPI 2.0 (Swagger), future versions of the OpenAPI specification, an
OWS Common 2.0 capabilities document or WSDL.
The Core is intended to be a minimal useful API for fine-grained read-access to a spatial dataset where
geometries are represented in the coordinate reference system WGS 84 with axis order longitude/
latitude.
Additional capabilities, e.g. support for transactions, complex data structures, rich queries, other
coordinate reference systems, subscription/notification, and returning aggregated results, may be
specified in future parts of the OGC API Features series or as vendor-specific extensions.
Conformance with this document shall be checked using all the relevant tests specified in Annex A
(normative) of this document. The framework, concepts, and methodology for testing, and the criteria to
be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures
and the OGC Compliance Testing web site. Table 2 provides conformance class URIs
ISO 19168-1:2020(E)
Table 2 — Conformance class URIs
Conformance class URI
Core http:// www .opengis .net/ spec/ ogcapi -features -1/ 1 .0/ conf/ core
HTML http:// www .opengis .net/ spec/ ogcapi -features -1/ 1 .0/ conf/ html
GeoJSON http:// www .opengis .net/ spec/ ogcapi -features -1/ 1 .0/ conf/ geojson
GML, Simple Features Profile, Level 0 http:// www .opengis .net/ spec/ ogcapi -features -1/ 1 .0/ conf/ gmlsf0
GML, Simple Features Profile, Level 2 http:// www .opengis .net/ spec/ ogcapi -features -1/ 1 .0/ conf/ gmlsf2
OpenAPI Specification 3.0 http:// www .opengis .net/ spec/ ogcapi -features -1/ 1 .0/ conf/ oas30
5 Conventions
5.1 Identifiers
The normative provisions in this document are denoted by the URI http://www.opengis.net/spec/
ogcapi-features-1/1.0.
All requirements and conformance tests that appear in this document are denoted by partial URIs
which are relative to this base.
5.2 Link relations
To express relationships between resources, RFC 8288 (Web Linking) is used.
[3]
The following registered link relation types are used in this document.
— alternate: Refers to a substitute for this context.
— collection: The target IRI points to a resource which represents the collection resource for the
context IRI.
— describedby: Refers to a resource providing information about the link’s context.
— item: The target IRI points to a resource that is a member of the collection represented by the
context IRI.
— next: Indicates that the link’s context is a part of a series, and that the next in the series is the
link target.
— license: Refers to a license associated with this context.
— prev: Indicates that the link’s context is a part of a series, and that the previous in the series is the
link target.
— This relation is only used in examples.
— self: Conveys an identifier for the link’s context.
— service-desc: Identifies service description for the context that is primarily intended for
consumption by machines.
— API definitions are considered service descriptions.
— service-doc: Identifies service documentation for the context that is primarily intended for human
consumption.
4 © ISO 2020 – All rights reserved

ISO 19168-1:2020(E)
In addition, the following link relation types are used for which no applicable registered link relation
type could be identified.
— items: Refers to a resource that is comprised of members of the collection represented by the link’s
context.
— conformance: Refers to a resource that identifies the specifications that the link’s context
conforms to.
— data: Refers to the root resource of a dataset in an API.
Each resource representation includes an array of links. Implementations are free to add additional
links for all resources provided by the API. For example, an enclosure link could reference a bulk
download of a collection. Or a related link on a feature could reference a related feature.
5.3 Use of HTTPS
For simplicity, this document in general only refers to the HTTP protocol. This is not meant to exclude
the use of HTTPS but is a shorthand notation for "HTTP or HTTPS." In fact, most servers are expected to
use HTTPS, not HTTP.
5.4 HTTP URIs
This document does not restrict the lexical space of URIs used in the API beyond the requirements of
the HTTP and URI Syntax IETF RFCs. If URIs include reserved characters that are delimiters in the URI
[2]
subcomponent, these have to be percent-encoded. See RFC 3986:2005, Clause 2 for details.
5.5 API definition
5.5.1 General remarks
Good documentation is essential for every API so that developers can more easily learn how to use the
API. In the best case, documentation will be available in HTML and in a format that can be processed by
software to connect to the API.
This document specifies requirements and recommendations for APIs that share feature data and
that want to follow a standard way of doing so. In general, APIs will go beyond the requirements and
recommendations stated in this document, or other parts of the OGC API series of standards, and will
support additional operations, parameters, etc. that are specific to the API or the software tool used to
implement the API.
5.5.2 Role of OpenAPI
This document uses OpenAPI 3.0 fragments as examples and to formally state requirements. However,
using OpenAPI 3.0 is not required for implementing a server.
Therefore, the Core requirements class only requires that an API definition be provided and linked
from the landing page.
A separate requirements class is specified for API definitions that follow the OpenAPI specification
3.0. This does not preclude that in the future or in parallel, other versions of OpenAPI or other API
descriptions are provided by a server.
NOTE This approach is used to avoid lock-in to a specific approach to defining an API as it is expected that
the API landscape will continue to evolve.
In this document, fragments of OpenAPI definitions are shown in YAML (YAML Ain’t Markup Language)
[1]
since YAML is easier to read than JSON and is typically used in OpenAPI editors. YAML is described
by its authors as a human friendly data serialization standard for all programming languages.
ISO 19168-1:2020(E)
5.5.3 References to OpenAPI components in normative statements
Some normative statements (requirements, recommendations and permissions) use a phrase that a
component in the API definition of the server must be "based upon" a schema or parameter component
in the OGC schema repository.
In this case, the following changes to the pre-defined OpenAPI component are permitted.
— If the server supports an XML encoding, xml properties may be added to the relevant OpenAPI
schema components.
— The range of values of a parameter or property may be extended (additional values) or constrained
(if a subset of all possible values is applicable to the server). An example for a constrained range of
values is to explicitly specify the supported values of a string parameter or property using an enum.
— The default value of a parameter may be changed or added unless a requirement explicitly
prohibits this.
— Additional properties may be added to the schema definition of a Response Object.
— Informative text may be changed or added, e.g. comments or description properties.
For API definitions that do not conform to the OpenAPI Specification 3.0, the normative statement
should be interpreted in the context of the API definition language used.
5.5.4 Paths in OpenAPI definitions
All paths in an OpenAPI definition are relative to a base URL of the server.
EXAMPLE 1 URL of the OpenAPI definition.
If the OpenAPI Server Object looks like this:
servers:
- url: https://dev.example.org/
description: Development server
- url: https://data.example.org/
description: Production
...