Open Geospatial Consortium

Submission Date: <yyyy-mm-dd>

Approval Date:  <yyyy-mm-dd>

Publication Date:  <yyyy-mm-dd>

External identifier of this OGC® document: http://www.opengis.net/doc/IS/ogcapi-features-4/1.0

Internal reference number of this OGC® document:    20-002

Version: 1.0.0-SNAPSHOT (Editor’s draft)

Latest Published Draft: n/a

Category: OGC® Implementation Specification

Editors: TBD

OGC API - Features - Part 4: Simple Transactions

Copyright notice

Copyright © 2019 Open Geospatial Consortium

To obtain additional rights of use, visit http://www.opengeospatial.org/legal/

Warning

This document is not an OGC Standard. This document is distributed for review and comment. This document is subject to change without notice and may not be referred to as an OGC Standard.

Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

Document type:    OGC® Standard

Document subtype:    Interface

Document stage:    Draft

Document language:  English

License Agreement

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD.

THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

i. Abstract

OGC API standards define modular API building blocks to spatially enable Web APIs in a consistent way. The OpenAPI specification is used to define the API building blocks.

This extensions defines the behaviour of an API that allows resource instances to be added, replaced, modified and/or removed for a single collection.

Note
This specification is being developed in the OGC API - Features SWG but is being written as a generic extension that is applicable to a variety of resource types including features. The feature-specific portions of this extension are issolated to the clause titled Features. It is anticipated that the bulk of this extension will eventually be moved into 'OGC API - Common' and only the feature-specific content will remain to be managed by the 'OGC API - Features' SWG.
Caution
This is a DRAFT version of the 4th part of the OGC API - Features standards. This draft is not complete and there are open issues that are still under discussion.

ii. Keywords

The following are keywords to be used by search engines and document catalogues.

resource feature collection instance spatial data openapi transactions insert update delete add modify remove REST PUT POST DELETE PATCH

iii. Preface

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium Inc. shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

iv. Submitting organizations

The following organizations submitted this document to the Open Geospatial Consortium (OGC):

  • CubeWerx Inc.

  • interactive instruments GmbH

v. Submitters

All questions regarding this submission should be directed to the editors or the submitters:

Name

Affiliation

Clemens Portele (editor)

interactive instruments GmbH

Panagiotis (Peter) A. Vretanos (editor)

CubeWerx Inc.

1. Scope

This document specifies an extension that defined the behaviour of a server that supports simple transactions. Simple transactions are transactions that add, replace, modify or delete individual resources from a single collection.

Additional specifications will subsequently be created to handle complex transactions; that is transactions that require batch or atomic semantics.

Specifically, this document specifies:

  • How to add a new resource instance to a collection.

  • How to modify an existing resource from a collection; this includes entirely replacing the existing resource or simply modifying one or more parts of a resource.

  • How to remove an existing resource from a collection.

2. Conformance

This standard defines three requirements / conformance classes:

The standardization target is "Web APIs".

The URIs of the associated conformance classes are:

Table 1. Conformance class URIs
Conformance class URI

Simple Transactions

http://www.opengis.net/spec/ogcapi-features-4/1.0/conf/simpletx

PATCH Update

http://www.opengis.net/spec/ogcapi-features-4/1.0/conf/simpletx/patch-update

Features

http://www.opengis.net/spec/ogcapi-features-4/1.0/conf/features

Conformance with this standard shall be checked using all the relevant tests specified in Annex A 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.

3. References

The following normative documents contain provisions that, through reference in this text, constitute provisions of this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.

4. Terms, definitions and abbreviated terms

4.1. Terms and Definitions

This document uses the terms defined in Sub-clause 5.3 of [OGC 06-121r9], which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this standard.

For the purposes of this document, the following additional terms, definitions and abbreviated terms apply in addition to those defined in OGC API - Features - Part 1: Core.

4.1.1. collection items end point

the path of the end point from which the resources of items of a collection can be accesses

EXAMPLE: For features, the collection items end point is '/collections/{collectionId}/items'.

EXAMPLE: For processes, the collection items end point is '/processes'

4.1.2. resource end point

the path of the end point used to access a specific instance of a resource from a collection

EXAMPLE: For features, the resource end point is '/collections/{collectionId}/items/{featureId}'.

EXAMPLE: For processes, the resource end point is '/processes/{processId}'.

5. Conventions and background

See OGC API - Features - Part 1: Core, Clauses 5 and 6.

6. Requirements Class "Simple Transactions"

6.1. Overview

Requirements Class

http://www.opengis.net/spec/ogcapi-features-3/1.0/req/simpletx

Target type

Web API

Dependency

RFC 2616 (HTTP/1.1)

A server that implements this conformance class provides the ability to add, replace and remove individual resources from a collection.

The HTTP POST method is used to add a new resource instance to a collection.

The HTTP PUT method is used to replace an existing resource in a collection with a replacement resource.

Finally, the HTTP DELETE method is used to remove a resource from a collection.

Adding or replacing a resource requires that a representation of that resource be provided by the client. This standard does not mandate that a specific specific resource encoding be supported by a server.

Note
The use of the HTTP PATCH method is not defined in this conformance class. The PATCH Update conformance class defines the use of the HTTP PATCH method.
Note
In order to promote interoperability, each standard that extends this standard should make recommendations concerning the representation of resources. See Features for a discussion of feature representations.

6.1.1. HTTP status codes

API clients should be prepared to handle any legal HTTP or HTTPS status code.

The Status Codes listed in Table 2 are of particular relevance to implementors of this standard. Status codes 200, 201 and 404 are called out in API requirements. Therefore, support for these status codes is mandatory for all compliant implementations. The remainder of the status codes in Table 2 are not mandatory, but are important for the implementation of a well functioning API. Support for these status codes is strongly encouraged for both client and server implementations.

Table 2. Typical HTTP status codes
Status code Description

200

A successful request.

201

The server has been fulfilled the operation and a new resource has been created.

400

The server cannot or will not process the request due to an apparent client error. For example, a query parameter had an incorrect value.

401

The request requires user authentication. The response includes a WWW-Authenticate header field containing a challenge applicable to the requested resource.

403

The server understood the request, but is refusing to fulfill it. While status code 401 indicates missing or bad authentication, status code 403 indicates that authentication is not the issue, but the client is not authorized to perform the requested operation on the resource.

404

The requested resource does not exist on the server. For example, a path parameter had an incorrect value.

405

The request method is not supported. For example, a POST request was submitted, but the resource only supports GET requests.

406

Content negotiation failed. For example, the Accept header submitted in the request did not support any of the media types supported by the server for the requested resource.

500

An internal error occurred in the server.

More specific guidance is provided for each resource, where applicable.

Permission 1

/per/core/additional-status-codes

A

Servers may support other capabilities of the HTTP protocol and, therefore, may return other status codes than those listed in Table 2.

The API Description Document describes the HTTP status codes generated by that API. This should not be an exhaustive list of all possible status codes. It is not reasonable to expect an API designer to control the use of HTTP status codes which are not generated by their software. Therefore, it is recommended that the API Description Document limit itself to describing HTTP status codes relevant to the proper operation of the API application logic. Client implementations should be prepared to receive HTTP status codes in addition to those described in the API Description Document.

6.2. Adding a new resource to a collection (INSERT)

6.2.1. Sequence diagram

The following diagram illustrates the sequence diagram for adding a new resource to a collection.

   Client                                                          Server
     |                                                               |
     |   POST <collection items end point>   HTTP/1.1                |
     |   Content-Type: <MIME type of resource representation>        |
     |                                                               |
     |   ... Body contains representation of the resource ...        |
     |-------------------------------------------------------------->|
     |                                                               |
     |   HTTP/1.1 201 Created                                        |
     |   Location: <resource end point>                              |
     |<--------------------------------------------------------------|

The token '<collection items end point>' is the end point used to access resources from a collection. For example, in the case of features, this endpoint is defined by the path '/collections/{collectionId}/items' (see http://fix.me; in the case of processes, this end point is defined by the path '/processes' (see http://fix.me).

The token '<resource end point>' is the path use to access a specific resource from a collection. For example, for features, this end point is defined as '/collections/{collectionId}/items/{featureId}' (see http://fix.me); in the case of processes, this end point is defined by the path '/processes/{processId}' (see http://fix.me).

6.2.2. Operation

Requirement 1

/req/simpletx/insert/post-op

A

The server shall support the HTTP POST operation at the collection items end point.

6.2.3. Request body

6.2.3.1. Overview

Requirement 2

/req/simpletx/insert/body

A

The body of a POST request shall contain a representation of the resource to be added to the specified collection.

Permission 2

/per/simpletx/insert/body

A

A server may support any resource encoding in the body of a HTTP POST operation.

Requirement 3

/req/simpletx/insert/content-type

A

As per HTTP 1.1 (https://tools.ietf.org/html/rfc2616#section-14.17) the 'Content-Type' header shall be used to indicate the media type of a request body containing a representation of the resource to be added.

6.2.4. Response

Requirement 4

/req/simpletx/insert/response-rid

A

If the operation completes sucessfully, the server shall assign an identifier for the newly added resource.

Requirement 5

/req/simpletx/insert/response

A

A successful execution of the operation shall be reported as a response with a HTTP status code '201'.

B

The response shall include a 'Location' header with the URL of the newly added resource (i.e. path of the resource end point).

6.2.5. Exceptions

6.3. Replacing an existing resource (UPDATE)

6.3.1. Sequence diagram

The following diagram illustrates the sequence diagram for replacing an existing resource in a collection with a new resource. This could be a completely new resource or a new version of the existing resource; version control is not discussed in this standard.

   Client                                                          Server
     |                                                               |
     |   PUT <resource end point>   HTTP/1.1                         |
     |   Content-Type: <MIME type of replacement resource>           |
     |                                                               |
     |   ... Body contains representation of replacement resource ...|
     |-------------------------------------------------------------->|
     |                                                               |
     |   HTTP/1.1 200 OK                                             |
     |<--------------------------------------------------------------|

6.3.2. Operation

Requirement 6

/req/simpletx/update/put/put-op

A

For every resource in a collection, the server shall support the HTTP PUT operation.

6.3.3. Request body

6.3.4. Overview

Requirement 7

/req/simpletx/update/put/body

A

The body of a PUT request shall contain a representation of the replacement resource.

Permission 3

/per/simpletx/update/put/body

A

A server may support any resource encoding in the body of a HTTP PUT operation.

Requirement 8

/req/simpletx/update/put/content-type

A

As per HTTP 1.1 (https://tools.ietf.org/html/rfc2616#section-14.17) the 'Content-Type' header shall be used to indicate the media type of a request body containing a representation of the replacement resource.

6.3.5. Response

Requirement 9

/req/simpletx/update/put/response

A

A successful execution of the operation shall be reported as a response with a HTTP status code '200'.

6.3.6. Exceptions

The assignment of resource identifiers is the pervue of the server and as a result, clients cannot simply use the HTTP PUT operation to create new resource instance. Instead, the creation of new resource instances should be preformed using the HTTP POST operation as described in Adding a new resource to a collection.

Requirement 10

/req/simpletx/update/put/rid-exception

A

If the target resource does not exist then the server shall indicate an unsuccessful execution of the operation that shall be reported as a response with a HTTP status code '404'.

See also HTTP status codes.

6.4. Removing a resource from a collection (DELETE)

6.4.1. Sequence diagram

The following diagram illustrates the sequence diagram for removing a resource from a collection.

   Client                                                          Server
     |                                                               |
     |   DELETE <resource end point>   HTTP/1.1                      |
     +-------------------------------------------------------------->|
     |                                                               |
     |   HTTP/1.1 200 OK                                             |
     +<--------------------------------------------------------------|

6.4.2. Operation

Requirement 11

/req/simpletx/delete/delete-op

A

For every resource in a collection, the server shall support the HTTP DELETE operation.

6.4.3. Response

Requirement 12

/req/simpletx/delete/response

A

A successful execution of the operation shall be reported as a response with a HTTP status code '200'.

6.4.4. Exceptions

7. Requirements Class "PATCH Update"

7.1. Overview

Requirements Class

http://www.opengis.net/spec/ogcapi-features-2/1.0/req/simpletx/patch-update

Target type

Web API

Dependency

RFC 2616 (HTTP/1.1)

Dependency

RFC 7396 (JSON Merge Patch)

Dependency

RFC 5261 (An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors)

A server that implements this conformance class provides the ability to use the HTTP PATCH method to modify parts of an existing resource without the need to transmit a complete replacement resource.

Modifying parts of a resource requires that a document describing the changes to be applied be provided by the client. This standard does not mandate that a specific encoding for this document be supported by a server. However, this extension provides requirements for the use of [rfc7396 (JSON Merge Patch)] for resource encoded using JSON (e.g. GeoJSON) and the use of [rfc5261 (An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors)] for resources encoded using XML (e.g. GML).

7.2. Modifying and existing resource (UPDATE)

7.2.1. Sequence diagram

The following diagram illustrates the sequence diagram for modifying part of an existing resource by only specifying the specific parts that should be updated.

   Client                                                          Server
     |                                                               |
     |   PATCH <resource end point>   HTTP/1.1                       |
     |   Content-Type: <MIME type of body>                           |
     |                                                               |
     |   ... Body contains a document describing the changes to make |
     |       to parts of the specfied resource ...                   |
     |-------------------------------------------------------------->|
     |                                                               |
     |   HTTP/1.1 200 OK                                             |
     |<--------------------------------------------------------------|

7.2.2. Operation

Requirement 13

/req/patch-update/update/patch/patch-op

A

For every resource in a collection, the server shall support the HTTP PATCH operation.

7.2.3. Request body

Requirement 14

/req/patch-ipdate/update/patch/body

A

The request body shall contain a document describing the specific parts of an identified resource (i.e. the target resource) that should be modified by the operation.

Recommendation 1

/rec/simpletx/update/patch/body-json-merge-patch

A

If a resource can be represented for the intended use in JSON, implementations should consider supporting the use of a JSON Merge Patch (RFC 7396) document for describing the incremental changes to be applied to a target resource.

B

The media type 'application/merge-patch+json’shall be used to indicate that request body contains a JSON Merge Patch document.

Recommendation 2

/rec/simpletx/update/patch/body-xml-patch

A

If a resource can be represented for the intended use in XML, implementations should consider supporting the use of a XML diff document (RFC 5261) for describing the incremental changes to be applied to a target resource.

B

The media type 'application/xml’shall be used to indicate that request body contains a XML diff document.

7.2.4. Response

Requirement 15

/req/patch-update/update/patch/response

A

A successful execution of the operation shall be reported as a response with a HTTP status code '200'.

7.2.5. Exceptions

8. Features

8.1. Overview

Requirements Class

http://www.opengis.net/spec/ogcapi-features-4/1.0/req/features

Target type

Web API

Dependency

OGC API - Features - Part 1: Core

This clause defines requirements for the case when the resource type is a feature.

8.2. Collection items end point

Requirement 16

/req/features/collection-items-end-point

A

For features, the collection items end point shall be the path '/collections/{collectionsId}/items'.

B

The parameter 'collectionId' is each 'id' property in the feature collection response (JSONPath: '$.collections[*].id').

8.3. Resource end point

Requirement 17

/req/features/feature-end-point

A

For features, the resource end point shall be the path '/collections/{collectionsId}/items/{featureId}'.

B

The parameter 'collectionId' is each 'id' property in the feature collection response (JSONPath: '$.collections[*].id').

C

The parameter 'featureId' is the 'id' property of a target feature (JSONPath: '$.features[*].id') obtained by previously having queried the collection (path '/collections/{collectionId}/items').

8.4. Representation of features

Adding or replacing a feature requires that a representation of that feature be provided by the client. As is the case in the core, this standard does not mandate that a specific feature encoding be supported by a server. However, in order to promote interoperability, this standard provides recommendations for features encoded using GeoJSON or GML.

Recommendation 3

/rec/features/representation-geojson

A

If a feature can be represented for the intended use in JSON, implementations should consider supporting GeoJSON as the encoding for the feature.

B

The media type 'application/geo+json’shall be used to indicate that request body contains a GeoJSON representation of the feature.

Recommendation 4

/rec/features/representation-gmlsf0

A

If a feature can be represented for the intended use as a GML feature that conforms to the GML Simple Feature Profile, Level 0 and is substitutable for 'gml:AbstractFeature', implementation should consider supporting GMLSF L0 as the encoding for the feature.

B

The media type 'application/gml+xml; version=3.2; profile="http://www.opengis.net/def/profile/ogc/2.0/gml-sf0"' shall be used to indicate that request body contains a GMLSF L0 representation of the feature.

Recommendation 18

/rec/features/representation-gmlsf2

A

If a feature can be represented for the intended use as a GML feature that conforms to the GML Simple Feature Profile, Level 2 and is substitutable for 'gml:AbstractFeature', implementation should consider supporting GMLSF L2 as the encoding for the feature.

B

The media type 'application/gml+xml; version=3.2; profile="http://www.opengis.net/def/profile/ogc/2.0/gml-sf2"' shall be used to indicate that request body contains a GMLSF L2 representation of the feature.

8.5. Coordinate reference systems

Requirement 19

/req/simpletx/crs/crs84

A

If a server implementing this standard does not support the Coordinate Reference Systems by Reference extension, then all geometry-valued feature properties presented to the server in a request body shall be expressed using CRS84 as per OGC API - Features - Part 1: Core.

Requirement 20

/req/simpletx/crs/storage-crs

A

If a server implementing this standard also supports the Coordinate Reference Systems by Reference extension, then all geometry-valued feature properties presented to the server in a request body shall be expressed using the storage crs advertised by the server (see OGC API - Features - Part 2: Coordinate Reference Systems by Reference, Storage CRS for the collection being operated on.

B

The specific collection being operated on is indicated by the {collectionId} component of the resource path.

GML has full CRS support and no further requirements are imposed by this standard.

GeoJSON normatively supports WGS84 (lon,lat) but the "prior arrangement" provision allows other coordinate reference systems to be used.

Requirement 21

/req/simpletx/crs/geojson

A

If a server implements this standard and also implements the Coordinate Reference Systems by Reference extension and the request body contains a feature encoded using GeoJSON then the prior arrangements provision of the GeoJSON standard (see https://tools.ietf.org/html/rfc7946#page-12) shall apply between the server and the client.

B

The feature in the request body shall thus be subject to requirement [req_simpletx_crs_storage-crs].

The use of HTML as a feature encoding format is not specified by this standard.

9. OpenAPI 3.0

10. Media Types

Additional JSON media types that would typically be used in a server that supports JSON are:

  • application/merge-patch+json

  • application/json-patch+json

Additional XML media types that would typically be used in a server that supports XML are:

11. Security Considerations

Users making modifications to resources need to:

  1. be authenticated

  2. have "modification privileges" on one or more of the resource collections offered by the API

  3. have access to one or more of the POST, PUT, PATCH and/or DELETE methods

The specific priviledges that a user posessed need to be reflected in the resource paths and available methods described in the API document.

Annex A: Abstract Test Suite (Normative)

A.1. Introduction

Note
This needs to be updated.

OGC API Features is not a Web Service in the traditional sense. Rather, it defines the behavior and content of a set of Resources exposed through a Web Application Programing Interface (Web API). Therefore, an API may expose resources in addition to those defined by the standard. A test engine must be able to traverse the API, identify and validate test points, and ignore resource paths which are not to be tested.

A.2. Conformance Class Simple Transactions

Requirements Class

http://www.opengis.net/spec/ogcapi-features-3/1.0/req/simpletx

Target type

Web API

Dependency

RFC 2616 (HTTP/1.1)

A.4. Conformance Class Features

Requirements Class

http://www.opengis.net/spec/ogcapi-features-4/1.0/req/features

Target type

Web API

Dependency

OGC API - Features - Part 1: Core

Annex B: Revision History

Date Release Editor Primary clauses modified Description

2019-xx-xx

1.0.0-SNAPSHOT

J. Doe

all

initial version

Annex C: Bibliography