Compliance to OGC Web API Guidelines

OGC API - Discrete Global Grid Systems - Part 1: Core (version-number)

To comply with Policy Directive 50, the following should be completed.

See an example in the OGC API - Common - Part 1: Core Standard.

#	Principle	Discussion
1	Don’t reinvent	This standard re-uses several building blocks shared across OGC APIs, including the ability to provide DGGS resources for landing page and collections as defined in OGC API - Common. Only DGGS-specific resources are introduced, based on the foundations of OGC Abstract Specification Topic 21.
2	Keep it simple and intuitive	This standard is organized in two primary requirement classes to answer simple questions of the type "What is here?" and "Where is it?", in addition to a Core defining how to list available Discrete Global Grid Reference Systems (DGGRS) and provide the necessary information for a particular DGGRS.
3	Use well-known resource types	This standard supports associating DGGS resources with OGC API - Common resource types (landing page and collections). For the new JSON information resource types introduced and the zone listing resource, at minimum a JSON representation is needed. For the zone data resources, no specific encoding is required, but requirement classes are defined clarifying the content of the response along with the respective media types.
4	Construct consistent URIs	This standard follows the convention and patterns of OGC API - Common and those of other OGC API standards. The new URIs introduced form a consistent set of resource paths: .../dggs, .../dggs/{dggrsId}, .../dggs/{dggrsId}/zones and .../dggs/{dggrsId}/zones/{zoneId}, and .../dggs/{dggrsId}/zones/{zoneId}/data.
5	Use HTTP methods consistent with RFC 7231	OGC web APIs are restricted to the HTTP methods defined in IETF RFC 7231.
6	Put selection criteria behind the ‘?’	Except for the DGGRS and zone identifiers, all selection criteria are after the ?. The DGGRS is for identifying a particular DGGRS (an API could potentially support more than one), whereas the zone identifier is the key DGGS resource concept akin to the OGC API - Tiles level/row/column, where using a path parameter facilitates the use of caching in static server deployments. These path parameters could be considered identifying criteria rather than selection criteria.
7	Error handling and use of HTTP status codes	This standard identifies relevant status codes for responses in specific requirements, consistent with HTTP (e.g., 200 for successful response and 400 for client errors).
8	Use explicit list of HTTP status codes	The same non-exhaustive explicit list of HTTP status code from OGC API - Common is also applicable to this standard.
9	Use of HTTP header	This standard relies on the HTTP Accept: and Accept-Encoding: request headers, as well as the Content-Type: and Content-Encoding: for content negotiation, and other relevant headers as defined by HTTP.
10	Allow flexible content negotiation	The zone data encodings, zone list encodings, as well as DGGS information resources support flexible content negotiation. A special content selection mechanism (e.g., f query parameter or .<extension>) may also be used where headers are not available.
11	Pagination	A recommendation is made to support limit on zone queries. However, since this may not be practical to implement, the parent-zone parameter provides an alternative hierarchical exploration mechanism more suitable to the DGGS query paradigm.
12	Processing resources	The DGGS API allows to perform zone queries and retrieve DGGS data from both static collections of data as well as from virtual resources resulting from a processing workflow, where a DGGS query will trigger on-demand processing, as defined in OGC API - Processes - Part 3: Workflows "Collection Output" requirement class.
13	Support metadata	In addition to dataset metadata and collection metadata inherited from OGC API - Common, the DGGS API supports requesting the list of available DGGRS, information about a particular DGGRS, information about a particular zone. The zone data encodings also support metadata, including a definition of fields and dimensions in the DGGS-JSON encoding.
14	Consider your security needs	A section details some security considerations when implementing this standard. DGGS resources may be associated with resources only available to authenticated users. The use of HTTPS is encouraged.
15	API description	An implementation of this standard can define its API as specified in OGC API - Common - Part 1 "Landing Page" requirement class. An "Operation IDs" requiremnt class defines suffixes to use to enable a client reading the API definition to identify resource paths with the relevant requirements of this standard.
16	Use well-known identifiers	IANA link relation types are used where applicable. New DGGS link relation types are defined for new concepts specific to this standard. The concept of a Discrete Global Grid Reference System (DGGRS) is introduced, with an informative schema and examples in annex B, with a plan to have a DGGRS registry set up by the OGC Naming Authority to provide DGGRS identifiers.
17	Use explicit relations	All relations in this standard are typed using relation types registered in the IANA or the OGC relation type registers.
18	Support W3C cross-origin resource sharing	The recommendation to support Cross-Origin request from OGC API - Common applies to this standard as well.
19	Resource encodings	Requirement classes for encodings of Zone Data and Zone lists are defined in this standard. Of these, only the JSON zone listing is mandatory. Additional and new encodings of both zone data and zone lists can also be defined and implemented.
20	Good APIs are testable from the beginning	The Abstract Test Suite (ATS) for this standard is provided in Annex A. The ATS is defined to sufficient level of detail to validate that it is implementable and comprehensive.
21	Specify whether operations are safe and/or idempotent	All request methods in this standard (GET) are both safe and idempotent.
22	Make resources discoverable	All resources defined in this standard can be navigated to through resource links and link templates with well-defined link relation types, as well as fixed paths relative to a particular resource for which the DGGS API is available. In addition, an implementation can implement OGC API - Common - Part 1 "Landing Page" requirement class which requires providing an API definition, in which case implementing the "Operation IDs" requirement class allows a client to associate resource paths with related requirements.
23	Make default behavior explicit	The requirements and API definition examples in this Standard specifies default behaviors. In some cases, the default behavior, such as the default relative depth for zone data retrieval, is specific to the implementation, deployment and/or the encoding and indicated in a resource (defaultDepth at .../dggs/{dggrsId}).