From b2cc206c4eb19a2eda42596794b48e766e6ec9df Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 18:57:17 +0100 Subject: [PATCH 01/34] Create README.md --- ogc-web-api-guidelines/README.md | 1 + 1 file changed, 1 insertion(+) create mode 100644 ogc-web-api-guidelines/README.md diff --git a/ogc-web-api-guidelines/README.md b/ogc-web-api-guidelines/README.md new file mode 100644 index 000000000..3f363dcfc --- /dev/null +++ b/ogc-web-api-guidelines/README.md @@ -0,0 +1 @@ +This folder contains the checklists for each version of OGC API EDR standard and its Parts. From 9b8ee0993e378be78826f81f14f0581d04d4292f Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 19:01:19 +0100 Subject: [PATCH 02/34] Create OGC API EDR Part 2: PubSub --- .../OGC API EDR Part 2: PubSub | 68 +++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 ogc-web-api-guidelines/OGC API EDR Part 2: PubSub diff --git a/ogc-web-api-guidelines/OGC API EDR Part 2: PubSub b/ogc-web-api-guidelines/OGC API EDR Part 2: PubSub new file mode 100644 index 000000000..8a654c7cc --- /dev/null +++ b/ogc-web-api-guidelines/OGC API EDR Part 2: PubSub @@ -0,0 +1,68 @@ +## OGC API - Environmental Data Retrieval (version-number) + +To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. + +See an example in the [OGC API - Common - Part 1: Core Standard](https://docs.ogc.org/is/19-072/19-072.html#_c483b499-4a80-4d7d-997e-100e0d89a0b3). + + + +| # | Principle | Discussion +| -- | -- | -- +| 1 | Don’t reinvent | +| 2 | Keep it simple and intuitive | +| 3 | Use well-known resource types | +| 4 | Construct consistent URIs | +| 5 | Use HTTP methods consistent with RFC 7231 | +| 6 | Put selection criteria behind the ‘?’ | +| 7 | Error handling and use of HTTP status codes | +| 8 | Use explicit list of HTTP status codes | +| 9 | Use of HTTP header | +| 10 | Allow flexible content negotiation | +| 11 | Pagination | +| 12 | Processing resources | +| 13 | Support metadata | +| 14 | Consider your security needs | +| 15 | API description | +| 16 | Use well-known identifiers | +| 17 | Use explicit relations | +| 18 | Support W3C cross-origin resource sharing | +| 19 | Resource encodings | +| 20 | Good APIs are testable from the beginning | +| 21 | Specify whether operations are safe and/or idempotent | +| 22 | Make resources discoverable | +| 23 | Make default behavior explicit | + + +## OGC API - Environmental Data Retrieval - Part 2: Publish-Subscribe Workflows (version-number) + +To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. + +See an example on the [OGC-Web-API-Guidelines](https://github.com/opengeospatial/OGC-Web-API-Guidelines/blob/master/Examples/API-Common-Core_api_guidelines.adoc) repo. + + +| # | Principle | Discussion +| -- | -- | -- +| 1 | Don’t reinvent | +| 2 | Keep it simple and intuitive | +| 3 | Use well-known resource types | +| 4 | Construct consistent URIs | +| 5 | Use HTTP methods consistent with RFC 7231 | +| 6 | Put selection criteria behind the ‘?’ | +| 7 | Error handling and use of HTTP status codes | +| 8 | Use explicit list of HTTP status codes | +| 9 | Use of HTTP header | +| 10 | Allow flexible content negotiation | +| 11 | Pagination | +| 12 | Processing resources | +| 13 | Support metadata | +| 14 | Consider your security needs | +| 15 | API description | +| 16 | Use well-known identifiers | +| 17 | Use explicit relations | +| 18 | Support W3C cross-origin resource sharing | +| 19 | Resource encodings | +| 20 | Good APIs are testable from the beginning | +| 21 | Specify whether operations are safe and/or idempotent | +| 22 | Make resources discoverable | +| 23 | Make default behavior explicit | + From 1e294e9880979725247b02fa42a3616dbd17affb Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 19:02:05 +0100 Subject: [PATCH 03/34] Create OGC API EDR Part 1: V1.2 --- .../OGC API EDR Part 1: V1.2 | 68 +++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 ogc-web-api-guidelines/OGC API EDR Part 1: V1.2 diff --git a/ogc-web-api-guidelines/OGC API EDR Part 1: V1.2 b/ogc-web-api-guidelines/OGC API EDR Part 1: V1.2 new file mode 100644 index 000000000..8a654c7cc --- /dev/null +++ b/ogc-web-api-guidelines/OGC API EDR Part 1: V1.2 @@ -0,0 +1,68 @@ +## OGC API - Environmental Data Retrieval (version-number) + +To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. + +See an example in the [OGC API - Common - Part 1: Core Standard](https://docs.ogc.org/is/19-072/19-072.html#_c483b499-4a80-4d7d-997e-100e0d89a0b3). + + + +| # | Principle | Discussion +| -- | -- | -- +| 1 | Don’t reinvent | +| 2 | Keep it simple and intuitive | +| 3 | Use well-known resource types | +| 4 | Construct consistent URIs | +| 5 | Use HTTP methods consistent with RFC 7231 | +| 6 | Put selection criteria behind the ‘?’ | +| 7 | Error handling and use of HTTP status codes | +| 8 | Use explicit list of HTTP status codes | +| 9 | Use of HTTP header | +| 10 | Allow flexible content negotiation | +| 11 | Pagination | +| 12 | Processing resources | +| 13 | Support metadata | +| 14 | Consider your security needs | +| 15 | API description | +| 16 | Use well-known identifiers | +| 17 | Use explicit relations | +| 18 | Support W3C cross-origin resource sharing | +| 19 | Resource encodings | +| 20 | Good APIs are testable from the beginning | +| 21 | Specify whether operations are safe and/or idempotent | +| 22 | Make resources discoverable | +| 23 | Make default behavior explicit | + + +## OGC API - Environmental Data Retrieval - Part 2: Publish-Subscribe Workflows (version-number) + +To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. + +See an example on the [OGC-Web-API-Guidelines](https://github.com/opengeospatial/OGC-Web-API-Guidelines/blob/master/Examples/API-Common-Core_api_guidelines.adoc) repo. + + +| # | Principle | Discussion +| -- | -- | -- +| 1 | Don’t reinvent | +| 2 | Keep it simple and intuitive | +| 3 | Use well-known resource types | +| 4 | Construct consistent URIs | +| 5 | Use HTTP methods consistent with RFC 7231 | +| 6 | Put selection criteria behind the ‘?’ | +| 7 | Error handling and use of HTTP status codes | +| 8 | Use explicit list of HTTP status codes | +| 9 | Use of HTTP header | +| 10 | Allow flexible content negotiation | +| 11 | Pagination | +| 12 | Processing resources | +| 13 | Support metadata | +| 14 | Consider your security needs | +| 15 | API description | +| 16 | Use well-known identifiers | +| 17 | Use explicit relations | +| 18 | Support W3C cross-origin resource sharing | +| 19 | Resource encodings | +| 20 | Good APIs are testable from the beginning | +| 21 | Specify whether operations are safe and/or idempotent | +| 22 | Make resources discoverable | +| 23 | Make default behavior explicit | + From 33c3d554f83fa32b9c5a4278eee10b808c0e255f Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 19:02:36 +0100 Subject: [PATCH 04/34] Create OGC API EDR V1.1 --- ogc-web-api-guidelines/OGC API EDR V1.1 | 68 +++++++++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 ogc-web-api-guidelines/OGC API EDR V1.1 diff --git a/ogc-web-api-guidelines/OGC API EDR V1.1 b/ogc-web-api-guidelines/OGC API EDR V1.1 new file mode 100644 index 000000000..8a654c7cc --- /dev/null +++ b/ogc-web-api-guidelines/OGC API EDR V1.1 @@ -0,0 +1,68 @@ +## OGC API - Environmental Data Retrieval (version-number) + +To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. + +See an example in the [OGC API - Common - Part 1: Core Standard](https://docs.ogc.org/is/19-072/19-072.html#_c483b499-4a80-4d7d-997e-100e0d89a0b3). + + + +| # | Principle | Discussion +| -- | -- | -- +| 1 | Don’t reinvent | +| 2 | Keep it simple and intuitive | +| 3 | Use well-known resource types | +| 4 | Construct consistent URIs | +| 5 | Use HTTP methods consistent with RFC 7231 | +| 6 | Put selection criteria behind the ‘?’ | +| 7 | Error handling and use of HTTP status codes | +| 8 | Use explicit list of HTTP status codes | +| 9 | Use of HTTP header | +| 10 | Allow flexible content negotiation | +| 11 | Pagination | +| 12 | Processing resources | +| 13 | Support metadata | +| 14 | Consider your security needs | +| 15 | API description | +| 16 | Use well-known identifiers | +| 17 | Use explicit relations | +| 18 | Support W3C cross-origin resource sharing | +| 19 | Resource encodings | +| 20 | Good APIs are testable from the beginning | +| 21 | Specify whether operations are safe and/or idempotent | +| 22 | Make resources discoverable | +| 23 | Make default behavior explicit | + + +## OGC API - Environmental Data Retrieval - Part 2: Publish-Subscribe Workflows (version-number) + +To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. + +See an example on the [OGC-Web-API-Guidelines](https://github.com/opengeospatial/OGC-Web-API-Guidelines/blob/master/Examples/API-Common-Core_api_guidelines.adoc) repo. + + +| # | Principle | Discussion +| -- | -- | -- +| 1 | Don’t reinvent | +| 2 | Keep it simple and intuitive | +| 3 | Use well-known resource types | +| 4 | Construct consistent URIs | +| 5 | Use HTTP methods consistent with RFC 7231 | +| 6 | Put selection criteria behind the ‘?’ | +| 7 | Error handling and use of HTTP status codes | +| 8 | Use explicit list of HTTP status codes | +| 9 | Use of HTTP header | +| 10 | Allow flexible content negotiation | +| 11 | Pagination | +| 12 | Processing resources | +| 13 | Support metadata | +| 14 | Consider your security needs | +| 15 | API description | +| 16 | Use well-known identifiers | +| 17 | Use explicit relations | +| 18 | Support W3C cross-origin resource sharing | +| 19 | Resource encodings | +| 20 | Good APIs are testable from the beginning | +| 21 | Specify whether operations are safe and/or idempotent | +| 22 | Make resources discoverable | +| 23 | Make default behavior explicit | + From 5258cd6f6ffdc4b7d5b5893f718b8932bd856d4f Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 19:07:17 +0100 Subject: [PATCH 05/34] Create OGC API EDR Checklist V1.0 --- .../OGC API EDR Checklist V1.0 | 68 +++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 ogc-web-api-guidelines/OGC API EDR Checklist V1.0 diff --git a/ogc-web-api-guidelines/OGC API EDR Checklist V1.0 b/ogc-web-api-guidelines/OGC API EDR Checklist V1.0 new file mode 100644 index 000000000..8a654c7cc --- /dev/null +++ b/ogc-web-api-guidelines/OGC API EDR Checklist V1.0 @@ -0,0 +1,68 @@ +## OGC API - Environmental Data Retrieval (version-number) + +To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. + +See an example in the [OGC API - Common - Part 1: Core Standard](https://docs.ogc.org/is/19-072/19-072.html#_c483b499-4a80-4d7d-997e-100e0d89a0b3). + + + +| # | Principle | Discussion +| -- | -- | -- +| 1 | Don’t reinvent | +| 2 | Keep it simple and intuitive | +| 3 | Use well-known resource types | +| 4 | Construct consistent URIs | +| 5 | Use HTTP methods consistent with RFC 7231 | +| 6 | Put selection criteria behind the ‘?’ | +| 7 | Error handling and use of HTTP status codes | +| 8 | Use explicit list of HTTP status codes | +| 9 | Use of HTTP header | +| 10 | Allow flexible content negotiation | +| 11 | Pagination | +| 12 | Processing resources | +| 13 | Support metadata | +| 14 | Consider your security needs | +| 15 | API description | +| 16 | Use well-known identifiers | +| 17 | Use explicit relations | +| 18 | Support W3C cross-origin resource sharing | +| 19 | Resource encodings | +| 20 | Good APIs are testable from the beginning | +| 21 | Specify whether operations are safe and/or idempotent | +| 22 | Make resources discoverable | +| 23 | Make default behavior explicit | + + +## OGC API - Environmental Data Retrieval - Part 2: Publish-Subscribe Workflows (version-number) + +To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. + +See an example on the [OGC-Web-API-Guidelines](https://github.com/opengeospatial/OGC-Web-API-Guidelines/blob/master/Examples/API-Common-Core_api_guidelines.adoc) repo. + + +| # | Principle | Discussion +| -- | -- | -- +| 1 | Don’t reinvent | +| 2 | Keep it simple and intuitive | +| 3 | Use well-known resource types | +| 4 | Construct consistent URIs | +| 5 | Use HTTP methods consistent with RFC 7231 | +| 6 | Put selection criteria behind the ‘?’ | +| 7 | Error handling and use of HTTP status codes | +| 8 | Use explicit list of HTTP status codes | +| 9 | Use of HTTP header | +| 10 | Allow flexible content negotiation | +| 11 | Pagination | +| 12 | Processing resources | +| 13 | Support metadata | +| 14 | Consider your security needs | +| 15 | API description | +| 16 | Use well-known identifiers | +| 17 | Use explicit relations | +| 18 | Support W3C cross-origin resource sharing | +| 19 | Resource encodings | +| 20 | Good APIs are testable from the beginning | +| 21 | Specify whether operations are safe and/or idempotent | +| 22 | Make resources discoverable | +| 23 | Make default behavior explicit | + From 13bc45704f37ebe059391d480cb87cfa32331c15 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 19:08:08 +0100 Subject: [PATCH 06/34] Create OGC API EDR Checklist V1.1 --- .../OGC API EDR Checklist V1.1 | 68 +++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 ogc-web-api-guidelines/OGC API EDR Checklist V1.1 diff --git a/ogc-web-api-guidelines/OGC API EDR Checklist V1.1 b/ogc-web-api-guidelines/OGC API EDR Checklist V1.1 new file mode 100644 index 000000000..8a654c7cc --- /dev/null +++ b/ogc-web-api-guidelines/OGC API EDR Checklist V1.1 @@ -0,0 +1,68 @@ +## OGC API - Environmental Data Retrieval (version-number) + +To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. + +See an example in the [OGC API - Common - Part 1: Core Standard](https://docs.ogc.org/is/19-072/19-072.html#_c483b499-4a80-4d7d-997e-100e0d89a0b3). + + + +| # | Principle | Discussion +| -- | -- | -- +| 1 | Don’t reinvent | +| 2 | Keep it simple and intuitive | +| 3 | Use well-known resource types | +| 4 | Construct consistent URIs | +| 5 | Use HTTP methods consistent with RFC 7231 | +| 6 | Put selection criteria behind the ‘?’ | +| 7 | Error handling and use of HTTP status codes | +| 8 | Use explicit list of HTTP status codes | +| 9 | Use of HTTP header | +| 10 | Allow flexible content negotiation | +| 11 | Pagination | +| 12 | Processing resources | +| 13 | Support metadata | +| 14 | Consider your security needs | +| 15 | API description | +| 16 | Use well-known identifiers | +| 17 | Use explicit relations | +| 18 | Support W3C cross-origin resource sharing | +| 19 | Resource encodings | +| 20 | Good APIs are testable from the beginning | +| 21 | Specify whether operations are safe and/or idempotent | +| 22 | Make resources discoverable | +| 23 | Make default behavior explicit | + + +## OGC API - Environmental Data Retrieval - Part 2: Publish-Subscribe Workflows (version-number) + +To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. + +See an example on the [OGC-Web-API-Guidelines](https://github.com/opengeospatial/OGC-Web-API-Guidelines/blob/master/Examples/API-Common-Core_api_guidelines.adoc) repo. + + +| # | Principle | Discussion +| -- | -- | -- +| 1 | Don’t reinvent | +| 2 | Keep it simple and intuitive | +| 3 | Use well-known resource types | +| 4 | Construct consistent URIs | +| 5 | Use HTTP methods consistent with RFC 7231 | +| 6 | Put selection criteria behind the ‘?’ | +| 7 | Error handling and use of HTTP status codes | +| 8 | Use explicit list of HTTP status codes | +| 9 | Use of HTTP header | +| 10 | Allow flexible content negotiation | +| 11 | Pagination | +| 12 | Processing resources | +| 13 | Support metadata | +| 14 | Consider your security needs | +| 15 | API description | +| 16 | Use well-known identifiers | +| 17 | Use explicit relations | +| 18 | Support W3C cross-origin resource sharing | +| 19 | Resource encodings | +| 20 | Good APIs are testable from the beginning | +| 21 | Specify whether operations are safe and/or idempotent | +| 22 | Make resources discoverable | +| 23 | Make default behavior explicit | + From e917ebc66af5ec6e47b1b489e1cbe4918bd08514 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 19:09:12 +0100 Subject: [PATCH 07/34] Create OGC API EDR Part 1 Checklist V1.2 --- .../OGC API EDR Part 1 Checklist V1.2 | 68 +++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 ogc-web-api-guidelines/OGC API EDR Part 1 Checklist V1.2 diff --git a/ogc-web-api-guidelines/OGC API EDR Part 1 Checklist V1.2 b/ogc-web-api-guidelines/OGC API EDR Part 1 Checklist V1.2 new file mode 100644 index 000000000..8a654c7cc --- /dev/null +++ b/ogc-web-api-guidelines/OGC API EDR Part 1 Checklist V1.2 @@ -0,0 +1,68 @@ +## OGC API - Environmental Data Retrieval (version-number) + +To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. + +See an example in the [OGC API - Common - Part 1: Core Standard](https://docs.ogc.org/is/19-072/19-072.html#_c483b499-4a80-4d7d-997e-100e0d89a0b3). + + + +| # | Principle | Discussion +| -- | -- | -- +| 1 | Don’t reinvent | +| 2 | Keep it simple and intuitive | +| 3 | Use well-known resource types | +| 4 | Construct consistent URIs | +| 5 | Use HTTP methods consistent with RFC 7231 | +| 6 | Put selection criteria behind the ‘?’ | +| 7 | Error handling and use of HTTP status codes | +| 8 | Use explicit list of HTTP status codes | +| 9 | Use of HTTP header | +| 10 | Allow flexible content negotiation | +| 11 | Pagination | +| 12 | Processing resources | +| 13 | Support metadata | +| 14 | Consider your security needs | +| 15 | API description | +| 16 | Use well-known identifiers | +| 17 | Use explicit relations | +| 18 | Support W3C cross-origin resource sharing | +| 19 | Resource encodings | +| 20 | Good APIs are testable from the beginning | +| 21 | Specify whether operations are safe and/or idempotent | +| 22 | Make resources discoverable | +| 23 | Make default behavior explicit | + + +## OGC API - Environmental Data Retrieval - Part 2: Publish-Subscribe Workflows (version-number) + +To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. + +See an example on the [OGC-Web-API-Guidelines](https://github.com/opengeospatial/OGC-Web-API-Guidelines/blob/master/Examples/API-Common-Core_api_guidelines.adoc) repo. + + +| # | Principle | Discussion +| -- | -- | -- +| 1 | Don’t reinvent | +| 2 | Keep it simple and intuitive | +| 3 | Use well-known resource types | +| 4 | Construct consistent URIs | +| 5 | Use HTTP methods consistent with RFC 7231 | +| 6 | Put selection criteria behind the ‘?’ | +| 7 | Error handling and use of HTTP status codes | +| 8 | Use explicit list of HTTP status codes | +| 9 | Use of HTTP header | +| 10 | Allow flexible content negotiation | +| 11 | Pagination | +| 12 | Processing resources | +| 13 | Support metadata | +| 14 | Consider your security needs | +| 15 | API description | +| 16 | Use well-known identifiers | +| 17 | Use explicit relations | +| 18 | Support W3C cross-origin resource sharing | +| 19 | Resource encodings | +| 20 | Good APIs are testable from the beginning | +| 21 | Specify whether operations are safe and/or idempotent | +| 22 | Make resources discoverable | +| 23 | Make default behavior explicit | + From 3b119ce318725038a4548a12a11ef4e50d7956eb Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 19:09:56 +0100 Subject: [PATCH 08/34] Create OGC API EDR Part 2 Checklist V1.0 --- .../OGC API EDR Part 2 Checklist V1.0 | 68 +++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 ogc-web-api-guidelines/OGC API EDR Part 2 Checklist V1.0 diff --git a/ogc-web-api-guidelines/OGC API EDR Part 2 Checklist V1.0 b/ogc-web-api-guidelines/OGC API EDR Part 2 Checklist V1.0 new file mode 100644 index 000000000..8a654c7cc --- /dev/null +++ b/ogc-web-api-guidelines/OGC API EDR Part 2 Checklist V1.0 @@ -0,0 +1,68 @@ +## OGC API - Environmental Data Retrieval (version-number) + +To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. + +See an example in the [OGC API - Common - Part 1: Core Standard](https://docs.ogc.org/is/19-072/19-072.html#_c483b499-4a80-4d7d-997e-100e0d89a0b3). + + + +| # | Principle | Discussion +| -- | -- | -- +| 1 | Don’t reinvent | +| 2 | Keep it simple and intuitive | +| 3 | Use well-known resource types | +| 4 | Construct consistent URIs | +| 5 | Use HTTP methods consistent with RFC 7231 | +| 6 | Put selection criteria behind the ‘?’ | +| 7 | Error handling and use of HTTP status codes | +| 8 | Use explicit list of HTTP status codes | +| 9 | Use of HTTP header | +| 10 | Allow flexible content negotiation | +| 11 | Pagination | +| 12 | Processing resources | +| 13 | Support metadata | +| 14 | Consider your security needs | +| 15 | API description | +| 16 | Use well-known identifiers | +| 17 | Use explicit relations | +| 18 | Support W3C cross-origin resource sharing | +| 19 | Resource encodings | +| 20 | Good APIs are testable from the beginning | +| 21 | Specify whether operations are safe and/or idempotent | +| 22 | Make resources discoverable | +| 23 | Make default behavior explicit | + + +## OGC API - Environmental Data Retrieval - Part 2: Publish-Subscribe Workflows (version-number) + +To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. + +See an example on the [OGC-Web-API-Guidelines](https://github.com/opengeospatial/OGC-Web-API-Guidelines/blob/master/Examples/API-Common-Core_api_guidelines.adoc) repo. + + +| # | Principle | Discussion +| -- | -- | -- +| 1 | Don’t reinvent | +| 2 | Keep it simple and intuitive | +| 3 | Use well-known resource types | +| 4 | Construct consistent URIs | +| 5 | Use HTTP methods consistent with RFC 7231 | +| 6 | Put selection criteria behind the ‘?’ | +| 7 | Error handling and use of HTTP status codes | +| 8 | Use explicit list of HTTP status codes | +| 9 | Use of HTTP header | +| 10 | Allow flexible content negotiation | +| 11 | Pagination | +| 12 | Processing resources | +| 13 | Support metadata | +| 14 | Consider your security needs | +| 15 | API description | +| 16 | Use well-known identifiers | +| 17 | Use explicit relations | +| 18 | Support W3C cross-origin resource sharing | +| 19 | Resource encodings | +| 20 | Good APIs are testable from the beginning | +| 21 | Specify whether operations are safe and/or idempotent | +| 22 | Make resources discoverable | +| 23 | Make default behavior explicit | + From afc66f97b3957894e31bc49c6ca3478f4f1e53a2 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 19:12:31 +0100 Subject: [PATCH 09/34] Create OGC API EDR Part 1 Core Checklist V1.2 --- .../OGC API EDR Part 1 Core Checklist V1.2 | 68 +++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 ogc-web-api-guidelines/OGC API EDR Part 1 Core Checklist V1.2 diff --git a/ogc-web-api-guidelines/OGC API EDR Part 1 Core Checklist V1.2 b/ogc-web-api-guidelines/OGC API EDR Part 1 Core Checklist V1.2 new file mode 100644 index 000000000..8a654c7cc --- /dev/null +++ b/ogc-web-api-guidelines/OGC API EDR Part 1 Core Checklist V1.2 @@ -0,0 +1,68 @@ +## OGC API - Environmental Data Retrieval (version-number) + +To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. + +See an example in the [OGC API - Common - Part 1: Core Standard](https://docs.ogc.org/is/19-072/19-072.html#_c483b499-4a80-4d7d-997e-100e0d89a0b3). + + + +| # | Principle | Discussion +| -- | -- | -- +| 1 | Don’t reinvent | +| 2 | Keep it simple and intuitive | +| 3 | Use well-known resource types | +| 4 | Construct consistent URIs | +| 5 | Use HTTP methods consistent with RFC 7231 | +| 6 | Put selection criteria behind the ‘?’ | +| 7 | Error handling and use of HTTP status codes | +| 8 | Use explicit list of HTTP status codes | +| 9 | Use of HTTP header | +| 10 | Allow flexible content negotiation | +| 11 | Pagination | +| 12 | Processing resources | +| 13 | Support metadata | +| 14 | Consider your security needs | +| 15 | API description | +| 16 | Use well-known identifiers | +| 17 | Use explicit relations | +| 18 | Support W3C cross-origin resource sharing | +| 19 | Resource encodings | +| 20 | Good APIs are testable from the beginning | +| 21 | Specify whether operations are safe and/or idempotent | +| 22 | Make resources discoverable | +| 23 | Make default behavior explicit | + + +## OGC API - Environmental Data Retrieval - Part 2: Publish-Subscribe Workflows (version-number) + +To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. + +See an example on the [OGC-Web-API-Guidelines](https://github.com/opengeospatial/OGC-Web-API-Guidelines/blob/master/Examples/API-Common-Core_api_guidelines.adoc) repo. + + +| # | Principle | Discussion +| -- | -- | -- +| 1 | Don’t reinvent | +| 2 | Keep it simple and intuitive | +| 3 | Use well-known resource types | +| 4 | Construct consistent URIs | +| 5 | Use HTTP methods consistent with RFC 7231 | +| 6 | Put selection criteria behind the ‘?’ | +| 7 | Error handling and use of HTTP status codes | +| 8 | Use explicit list of HTTP status codes | +| 9 | Use of HTTP header | +| 10 | Allow flexible content negotiation | +| 11 | Pagination | +| 12 | Processing resources | +| 13 | Support metadata | +| 14 | Consider your security needs | +| 15 | API description | +| 16 | Use well-known identifiers | +| 17 | Use explicit relations | +| 18 | Support W3C cross-origin resource sharing | +| 19 | Resource encodings | +| 20 | Good APIs are testable from the beginning | +| 21 | Specify whether operations are safe and/or idempotent | +| 22 | Make resources discoverable | +| 23 | Make default behavior explicit | + From 4d53f74e75b72a5bae56735341bc714e6e309ce1 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 19:13:22 +0100 Subject: [PATCH 10/34] Create OGC API EDR Part 2 PubSub Checklist V1.0 --- .../OGC API EDR Part 2 PubSub Checklist V1.0 | 68 +++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 ogc-web-api-guidelines/OGC API EDR Part 2 PubSub Checklist V1.0 diff --git a/ogc-web-api-guidelines/OGC API EDR Part 2 PubSub Checklist V1.0 b/ogc-web-api-guidelines/OGC API EDR Part 2 PubSub Checklist V1.0 new file mode 100644 index 000000000..8a654c7cc --- /dev/null +++ b/ogc-web-api-guidelines/OGC API EDR Part 2 PubSub Checklist V1.0 @@ -0,0 +1,68 @@ +## OGC API - Environmental Data Retrieval (version-number) + +To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. + +See an example in the [OGC API - Common - Part 1: Core Standard](https://docs.ogc.org/is/19-072/19-072.html#_c483b499-4a80-4d7d-997e-100e0d89a0b3). + + + +| # | Principle | Discussion +| -- | -- | -- +| 1 | Don’t reinvent | +| 2 | Keep it simple and intuitive | +| 3 | Use well-known resource types | +| 4 | Construct consistent URIs | +| 5 | Use HTTP methods consistent with RFC 7231 | +| 6 | Put selection criteria behind the ‘?’ | +| 7 | Error handling and use of HTTP status codes | +| 8 | Use explicit list of HTTP status codes | +| 9 | Use of HTTP header | +| 10 | Allow flexible content negotiation | +| 11 | Pagination | +| 12 | Processing resources | +| 13 | Support metadata | +| 14 | Consider your security needs | +| 15 | API description | +| 16 | Use well-known identifiers | +| 17 | Use explicit relations | +| 18 | Support W3C cross-origin resource sharing | +| 19 | Resource encodings | +| 20 | Good APIs are testable from the beginning | +| 21 | Specify whether operations are safe and/or idempotent | +| 22 | Make resources discoverable | +| 23 | Make default behavior explicit | + + +## OGC API - Environmental Data Retrieval - Part 2: Publish-Subscribe Workflows (version-number) + +To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. + +See an example on the [OGC-Web-API-Guidelines](https://github.com/opengeospatial/OGC-Web-API-Guidelines/blob/master/Examples/API-Common-Core_api_guidelines.adoc) repo. + + +| # | Principle | Discussion +| -- | -- | -- +| 1 | Don’t reinvent | +| 2 | Keep it simple and intuitive | +| 3 | Use well-known resource types | +| 4 | Construct consistent URIs | +| 5 | Use HTTP methods consistent with RFC 7231 | +| 6 | Put selection criteria behind the ‘?’ | +| 7 | Error handling and use of HTTP status codes | +| 8 | Use explicit list of HTTP status codes | +| 9 | Use of HTTP header | +| 10 | Allow flexible content negotiation | +| 11 | Pagination | +| 12 | Processing resources | +| 13 | Support metadata | +| 14 | Consider your security needs | +| 15 | API description | +| 16 | Use well-known identifiers | +| 17 | Use explicit relations | +| 18 | Support W3C cross-origin resource sharing | +| 19 | Resource encodings | +| 20 | Good APIs are testable from the beginning | +| 21 | Specify whether operations are safe and/or idempotent | +| 22 | Make resources discoverable | +| 23 | Make default behavior explicit | + From 4eca92288d5075492c5503a9057d2825b2b57138 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 19:14:31 +0100 Subject: [PATCH 11/34] Update OGC API EDR Part 1 Checklist V1.2 --- .../OGC API EDR Part 1 Checklist V1.2 | 67 ------------------- 1 file changed, 67 deletions(-) diff --git a/ogc-web-api-guidelines/OGC API EDR Part 1 Checklist V1.2 b/ogc-web-api-guidelines/OGC API EDR Part 1 Checklist V1.2 index 8a654c7cc..8b1378917 100644 --- a/ogc-web-api-guidelines/OGC API EDR Part 1 Checklist V1.2 +++ b/ogc-web-api-guidelines/OGC API EDR Part 1 Checklist V1.2 @@ -1,68 +1 @@ -## OGC API - Environmental Data Retrieval (version-number) - -To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. - -See an example in the [OGC API - Common - Part 1: Core Standard](https://docs.ogc.org/is/19-072/19-072.html#_c483b499-4a80-4d7d-997e-100e0d89a0b3). - - - -| # | Principle | Discussion -| -- | -- | -- -| 1 | Don’t reinvent | -| 2 | Keep it simple and intuitive | -| 3 | Use well-known resource types | -| 4 | Construct consistent URIs | -| 5 | Use HTTP methods consistent with RFC 7231 | -| 6 | Put selection criteria behind the ‘?’ | -| 7 | Error handling and use of HTTP status codes | -| 8 | Use explicit list of HTTP status codes | -| 9 | Use of HTTP header | -| 10 | Allow flexible content negotiation | -| 11 | Pagination | -| 12 | Processing resources | -| 13 | Support metadata | -| 14 | Consider your security needs | -| 15 | API description | -| 16 | Use well-known identifiers | -| 17 | Use explicit relations | -| 18 | Support W3C cross-origin resource sharing | -| 19 | Resource encodings | -| 20 | Good APIs are testable from the beginning | -| 21 | Specify whether operations are safe and/or idempotent | -| 22 | Make resources discoverable | -| 23 | Make default behavior explicit | - - -## OGC API - Environmental Data Retrieval - Part 2: Publish-Subscribe Workflows (version-number) - -To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. - -See an example on the [OGC-Web-API-Guidelines](https://github.com/opengeospatial/OGC-Web-API-Guidelines/blob/master/Examples/API-Common-Core_api_guidelines.adoc) repo. - - -| # | Principle | Discussion -| -- | -- | -- -| 1 | Don’t reinvent | -| 2 | Keep it simple and intuitive | -| 3 | Use well-known resource types | -| 4 | Construct consistent URIs | -| 5 | Use HTTP methods consistent with RFC 7231 | -| 6 | Put selection criteria behind the ‘?’ | -| 7 | Error handling and use of HTTP status codes | -| 8 | Use explicit list of HTTP status codes | -| 9 | Use of HTTP header | -| 10 | Allow flexible content negotiation | -| 11 | Pagination | -| 12 | Processing resources | -| 13 | Support metadata | -| 14 | Consider your security needs | -| 15 | API description | -| 16 | Use well-known identifiers | -| 17 | Use explicit relations | -| 18 | Support W3C cross-origin resource sharing | -| 19 | Resource encodings | -| 20 | Good APIs are testable from the beginning | -| 21 | Specify whether operations are safe and/or idempotent | -| 22 | Make resources discoverable | -| 23 | Make default behavior explicit | From 8b92f49733f8587019fc7332b7460f74ca32094e Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 19:15:03 +0100 Subject: [PATCH 12/34] Update OGC API EDR Part 1: V1.2 --- .../OGC API EDR Part 1: V1.2 | 67 ------------------- 1 file changed, 67 deletions(-) diff --git a/ogc-web-api-guidelines/OGC API EDR Part 1: V1.2 b/ogc-web-api-guidelines/OGC API EDR Part 1: V1.2 index 8a654c7cc..8b1378917 100644 --- a/ogc-web-api-guidelines/OGC API EDR Part 1: V1.2 +++ b/ogc-web-api-guidelines/OGC API EDR Part 1: V1.2 @@ -1,68 +1 @@ -## OGC API - Environmental Data Retrieval (version-number) - -To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. - -See an example in the [OGC API - Common - Part 1: Core Standard](https://docs.ogc.org/is/19-072/19-072.html#_c483b499-4a80-4d7d-997e-100e0d89a0b3). - - - -| # | Principle | Discussion -| -- | -- | -- -| 1 | Don’t reinvent | -| 2 | Keep it simple and intuitive | -| 3 | Use well-known resource types | -| 4 | Construct consistent URIs | -| 5 | Use HTTP methods consistent with RFC 7231 | -| 6 | Put selection criteria behind the ‘?’ | -| 7 | Error handling and use of HTTP status codes | -| 8 | Use explicit list of HTTP status codes | -| 9 | Use of HTTP header | -| 10 | Allow flexible content negotiation | -| 11 | Pagination | -| 12 | Processing resources | -| 13 | Support metadata | -| 14 | Consider your security needs | -| 15 | API description | -| 16 | Use well-known identifiers | -| 17 | Use explicit relations | -| 18 | Support W3C cross-origin resource sharing | -| 19 | Resource encodings | -| 20 | Good APIs are testable from the beginning | -| 21 | Specify whether operations are safe and/or idempotent | -| 22 | Make resources discoverable | -| 23 | Make default behavior explicit | - - -## OGC API - Environmental Data Retrieval - Part 2: Publish-Subscribe Workflows (version-number) - -To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. - -See an example on the [OGC-Web-API-Guidelines](https://github.com/opengeospatial/OGC-Web-API-Guidelines/blob/master/Examples/API-Common-Core_api_guidelines.adoc) repo. - - -| # | Principle | Discussion -| -- | -- | -- -| 1 | Don’t reinvent | -| 2 | Keep it simple and intuitive | -| 3 | Use well-known resource types | -| 4 | Construct consistent URIs | -| 5 | Use HTTP methods consistent with RFC 7231 | -| 6 | Put selection criteria behind the ‘?’ | -| 7 | Error handling and use of HTTP status codes | -| 8 | Use explicit list of HTTP status codes | -| 9 | Use of HTTP header | -| 10 | Allow flexible content negotiation | -| 11 | Pagination | -| 12 | Processing resources | -| 13 | Support metadata | -| 14 | Consider your security needs | -| 15 | API description | -| 16 | Use well-known identifiers | -| 17 | Use explicit relations | -| 18 | Support W3C cross-origin resource sharing | -| 19 | Resource encodings | -| 20 | Good APIs are testable from the beginning | -| 21 | Specify whether operations are safe and/or idempotent | -| 22 | Make resources discoverable | -| 23 | Make default behavior explicit | From d24928e80bc896bb3e262b5bfc5184e8938427b8 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 19:15:32 +0100 Subject: [PATCH 13/34] Update OGC API EDR Part 2 Checklist V1.0 --- .../OGC API EDR Part 2 Checklist V1.0 | 67 ------------------- 1 file changed, 67 deletions(-) diff --git a/ogc-web-api-guidelines/OGC API EDR Part 2 Checklist V1.0 b/ogc-web-api-guidelines/OGC API EDR Part 2 Checklist V1.0 index 8a654c7cc..8b1378917 100644 --- a/ogc-web-api-guidelines/OGC API EDR Part 2 Checklist V1.0 +++ b/ogc-web-api-guidelines/OGC API EDR Part 2 Checklist V1.0 @@ -1,68 +1 @@ -## OGC API - Environmental Data Retrieval (version-number) - -To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. - -See an example in the [OGC API - Common - Part 1: Core Standard](https://docs.ogc.org/is/19-072/19-072.html#_c483b499-4a80-4d7d-997e-100e0d89a0b3). - - - -| # | Principle | Discussion -| -- | -- | -- -| 1 | Don’t reinvent | -| 2 | Keep it simple and intuitive | -| 3 | Use well-known resource types | -| 4 | Construct consistent URIs | -| 5 | Use HTTP methods consistent with RFC 7231 | -| 6 | Put selection criteria behind the ‘?’ | -| 7 | Error handling and use of HTTP status codes | -| 8 | Use explicit list of HTTP status codes | -| 9 | Use of HTTP header | -| 10 | Allow flexible content negotiation | -| 11 | Pagination | -| 12 | Processing resources | -| 13 | Support metadata | -| 14 | Consider your security needs | -| 15 | API description | -| 16 | Use well-known identifiers | -| 17 | Use explicit relations | -| 18 | Support W3C cross-origin resource sharing | -| 19 | Resource encodings | -| 20 | Good APIs are testable from the beginning | -| 21 | Specify whether operations are safe and/or idempotent | -| 22 | Make resources discoverable | -| 23 | Make default behavior explicit | - - -## OGC API - Environmental Data Retrieval - Part 2: Publish-Subscribe Workflows (version-number) - -To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. - -See an example on the [OGC-Web-API-Guidelines](https://github.com/opengeospatial/OGC-Web-API-Guidelines/blob/master/Examples/API-Common-Core_api_guidelines.adoc) repo. - - -| # | Principle | Discussion -| -- | -- | -- -| 1 | Don’t reinvent | -| 2 | Keep it simple and intuitive | -| 3 | Use well-known resource types | -| 4 | Construct consistent URIs | -| 5 | Use HTTP methods consistent with RFC 7231 | -| 6 | Put selection criteria behind the ‘?’ | -| 7 | Error handling and use of HTTP status codes | -| 8 | Use explicit list of HTTP status codes | -| 9 | Use of HTTP header | -| 10 | Allow flexible content negotiation | -| 11 | Pagination | -| 12 | Processing resources | -| 13 | Support metadata | -| 14 | Consider your security needs | -| 15 | API description | -| 16 | Use well-known identifiers | -| 17 | Use explicit relations | -| 18 | Support W3C cross-origin resource sharing | -| 19 | Resource encodings | -| 20 | Good APIs are testable from the beginning | -| 21 | Specify whether operations are safe and/or idempotent | -| 22 | Make resources discoverable | -| 23 | Make default behavior explicit | From a0c36151eedaec4f26ceb087aef1627499672958 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 19:16:01 +0100 Subject: [PATCH 14/34] Update OGC API EDR Part 2: PubSub --- .../OGC API EDR Part 2: PubSub | 67 ------------------- 1 file changed, 67 deletions(-) diff --git a/ogc-web-api-guidelines/OGC API EDR Part 2: PubSub b/ogc-web-api-guidelines/OGC API EDR Part 2: PubSub index 8a654c7cc..8b1378917 100644 --- a/ogc-web-api-guidelines/OGC API EDR Part 2: PubSub +++ b/ogc-web-api-guidelines/OGC API EDR Part 2: PubSub @@ -1,68 +1 @@ -## OGC API - Environmental Data Retrieval (version-number) - -To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. - -See an example in the [OGC API - Common - Part 1: Core Standard](https://docs.ogc.org/is/19-072/19-072.html#_c483b499-4a80-4d7d-997e-100e0d89a0b3). - - - -| # | Principle | Discussion -| -- | -- | -- -| 1 | Don’t reinvent | -| 2 | Keep it simple and intuitive | -| 3 | Use well-known resource types | -| 4 | Construct consistent URIs | -| 5 | Use HTTP methods consistent with RFC 7231 | -| 6 | Put selection criteria behind the ‘?’ | -| 7 | Error handling and use of HTTP status codes | -| 8 | Use explicit list of HTTP status codes | -| 9 | Use of HTTP header | -| 10 | Allow flexible content negotiation | -| 11 | Pagination | -| 12 | Processing resources | -| 13 | Support metadata | -| 14 | Consider your security needs | -| 15 | API description | -| 16 | Use well-known identifiers | -| 17 | Use explicit relations | -| 18 | Support W3C cross-origin resource sharing | -| 19 | Resource encodings | -| 20 | Good APIs are testable from the beginning | -| 21 | Specify whether operations are safe and/or idempotent | -| 22 | Make resources discoverable | -| 23 | Make default behavior explicit | - - -## OGC API - Environmental Data Retrieval - Part 2: Publish-Subscribe Workflows (version-number) - -To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. - -See an example on the [OGC-Web-API-Guidelines](https://github.com/opengeospatial/OGC-Web-API-Guidelines/blob/master/Examples/API-Common-Core_api_guidelines.adoc) repo. - - -| # | Principle | Discussion -| -- | -- | -- -| 1 | Don’t reinvent | -| 2 | Keep it simple and intuitive | -| 3 | Use well-known resource types | -| 4 | Construct consistent URIs | -| 5 | Use HTTP methods consistent with RFC 7231 | -| 6 | Put selection criteria behind the ‘?’ | -| 7 | Error handling and use of HTTP status codes | -| 8 | Use explicit list of HTTP status codes | -| 9 | Use of HTTP header | -| 10 | Allow flexible content negotiation | -| 11 | Pagination | -| 12 | Processing resources | -| 13 | Support metadata | -| 14 | Consider your security needs | -| 15 | API description | -| 16 | Use well-known identifiers | -| 17 | Use explicit relations | -| 18 | Support W3C cross-origin resource sharing | -| 19 | Resource encodings | -| 20 | Good APIs are testable from the beginning | -| 21 | Specify whether operations are safe and/or idempotent | -| 22 | Make resources discoverable | -| 23 | Make default behavior explicit | From 03a2cf5f7c57ae5a8b1644b32dd9db5b86b7d5f2 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 19:16:30 +0100 Subject: [PATCH 15/34] Update OGC API EDR V1.1 --- ogc-web-api-guidelines/OGC API EDR V1.1 | 67 ------------------------- 1 file changed, 67 deletions(-) diff --git a/ogc-web-api-guidelines/OGC API EDR V1.1 b/ogc-web-api-guidelines/OGC API EDR V1.1 index 8a654c7cc..8b1378917 100644 --- a/ogc-web-api-guidelines/OGC API EDR V1.1 +++ b/ogc-web-api-guidelines/OGC API EDR V1.1 @@ -1,68 +1 @@ -## OGC API - Environmental Data Retrieval (version-number) - -To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. - -See an example in the [OGC API - Common - Part 1: Core Standard](https://docs.ogc.org/is/19-072/19-072.html#_c483b499-4a80-4d7d-997e-100e0d89a0b3). - - - -| # | Principle | Discussion -| -- | -- | -- -| 1 | Don’t reinvent | -| 2 | Keep it simple and intuitive | -| 3 | Use well-known resource types | -| 4 | Construct consistent URIs | -| 5 | Use HTTP methods consistent with RFC 7231 | -| 6 | Put selection criteria behind the ‘?’ | -| 7 | Error handling and use of HTTP status codes | -| 8 | Use explicit list of HTTP status codes | -| 9 | Use of HTTP header | -| 10 | Allow flexible content negotiation | -| 11 | Pagination | -| 12 | Processing resources | -| 13 | Support metadata | -| 14 | Consider your security needs | -| 15 | API description | -| 16 | Use well-known identifiers | -| 17 | Use explicit relations | -| 18 | Support W3C cross-origin resource sharing | -| 19 | Resource encodings | -| 20 | Good APIs are testable from the beginning | -| 21 | Specify whether operations are safe and/or idempotent | -| 22 | Make resources discoverable | -| 23 | Make default behavior explicit | - - -## OGC API - Environmental Data Retrieval - Part 2: Publish-Subscribe Workflows (version-number) - -To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. - -See an example on the [OGC-Web-API-Guidelines](https://github.com/opengeospatial/OGC-Web-API-Guidelines/blob/master/Examples/API-Common-Core_api_guidelines.adoc) repo. - - -| # | Principle | Discussion -| -- | -- | -- -| 1 | Don’t reinvent | -| 2 | Keep it simple and intuitive | -| 3 | Use well-known resource types | -| 4 | Construct consistent URIs | -| 5 | Use HTTP methods consistent with RFC 7231 | -| 6 | Put selection criteria behind the ‘?’ | -| 7 | Error handling and use of HTTP status codes | -| 8 | Use explicit list of HTTP status codes | -| 9 | Use of HTTP header | -| 10 | Allow flexible content negotiation | -| 11 | Pagination | -| 12 | Processing resources | -| 13 | Support metadata | -| 14 | Consider your security needs | -| 15 | API description | -| 16 | Use well-known identifiers | -| 17 | Use explicit relations | -| 18 | Support W3C cross-origin resource sharing | -| 19 | Resource encodings | -| 20 | Good APIs are testable from the beginning | -| 21 | Specify whether operations are safe and/or idempotent | -| 22 | Make resources discoverable | -| 23 | Make default behavior explicit | From c6491db5946499ff8e6538b4c55e044410cb8d11 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 19:18:01 +0100 Subject: [PATCH 16/34] Update OGC API EDR Checklist V1.0 --- ogc-web-api-guidelines/OGC API EDR Checklist V1.0 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ogc-web-api-guidelines/OGC API EDR Checklist V1.0 b/ogc-web-api-guidelines/OGC API EDR Checklist V1.0 index 8a654c7cc..adefb4688 100644 --- a/ogc-web-api-guidelines/OGC API EDR Checklist V1.0 +++ b/ogc-web-api-guidelines/OGC API EDR Checklist V1.0 @@ -1,4 +1,4 @@ -## OGC API - Environmental Data Retrieval (version-number) +## OGC API - Environmental Data Retrieval Version 1.0 To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. From c1a5c9f8f8fc6759bb31d10ffdab85c7e993cdd8 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 19:18:40 +0100 Subject: [PATCH 17/34] Update OGC API EDR Checklist V1.1 --- ogc-web-api-guidelines/OGC API EDR Checklist V1.1 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ogc-web-api-guidelines/OGC API EDR Checklist V1.1 b/ogc-web-api-guidelines/OGC API EDR Checklist V1.1 index 8a654c7cc..d2e589b70 100644 --- a/ogc-web-api-guidelines/OGC API EDR Checklist V1.1 +++ b/ogc-web-api-guidelines/OGC API EDR Checklist V1.1 @@ -1,4 +1,4 @@ -## OGC API - Environmental Data Retrieval (version-number) +## OGC API - Environmental Data Retrieval Version 1.1 To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. From 98b4cb1e7f61c8260fbf9779fc295b9c0bc9420d Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 19:19:45 +0100 Subject: [PATCH 18/34] Update OGC API EDR Part 1 Core Checklist V1.2 --- ogc-web-api-guidelines/OGC API EDR Part 1 Core Checklist V1.2 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ogc-web-api-guidelines/OGC API EDR Part 1 Core Checklist V1.2 b/ogc-web-api-guidelines/OGC API EDR Part 1 Core Checklist V1.2 index 8a654c7cc..4ad9675a3 100644 --- a/ogc-web-api-guidelines/OGC API EDR Part 1 Core Checklist V1.2 +++ b/ogc-web-api-guidelines/OGC API EDR Part 1 Core Checklist V1.2 @@ -1,4 +1,4 @@ -## OGC API - Environmental Data Retrieval (version-number) +## OGC API - Environmental Data Retrieval Part 1: Core Version 1.2 To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. From ec38bfabfac4d01d046b1fe20c7c936e3b2f05d7 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 19:20:52 +0100 Subject: [PATCH 19/34] Update OGC API EDR Part 2 PubSub Checklist V1.0 --- ogc-web-api-guidelines/OGC API EDR Part 2 PubSub Checklist V1.0 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ogc-web-api-guidelines/OGC API EDR Part 2 PubSub Checklist V1.0 b/ogc-web-api-guidelines/OGC API EDR Part 2 PubSub Checklist V1.0 index 8a654c7cc..cfc551840 100644 --- a/ogc-web-api-guidelines/OGC API EDR Part 2 PubSub Checklist V1.0 +++ b/ogc-web-api-guidelines/OGC API EDR Part 2 PubSub Checklist V1.0 @@ -1,4 +1,4 @@ -## OGC API - Environmental Data Retrieval (version-number) +## OGC API - Environmental Data Retrieval Part 2: Publish-Subscribe Version 1.0 To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. From 7a9be8ac8b51df99f18ec029fd029ac5266a98fb Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 19:22:38 +0100 Subject: [PATCH 20/34] Delete ogc-web-api-guidelines/OGC API EDR Part 1 Checklist V1.2 --- ogc-web-api-guidelines/OGC API EDR Part 1 Checklist V1.2 | 1 - 1 file changed, 1 deletion(-) delete mode 100644 ogc-web-api-guidelines/OGC API EDR Part 1 Checklist V1.2 diff --git a/ogc-web-api-guidelines/OGC API EDR Part 1 Checklist V1.2 b/ogc-web-api-guidelines/OGC API EDR Part 1 Checklist V1.2 deleted file mode 100644 index 8b1378917..000000000 --- a/ogc-web-api-guidelines/OGC API EDR Part 1 Checklist V1.2 +++ /dev/null @@ -1 +0,0 @@ - From 4001a05864140b060cf565f09245bbf0792d060d Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 19:23:03 +0100 Subject: [PATCH 21/34] Delete ogc-web-api-guidelines/OGC API EDR Part 1: V1.2 --- ogc-web-api-guidelines/OGC API EDR Part 1: V1.2 | 1 - 1 file changed, 1 deletion(-) delete mode 100644 ogc-web-api-guidelines/OGC API EDR Part 1: V1.2 diff --git a/ogc-web-api-guidelines/OGC API EDR Part 1: V1.2 b/ogc-web-api-guidelines/OGC API EDR Part 1: V1.2 deleted file mode 100644 index 8b1378917..000000000 --- a/ogc-web-api-guidelines/OGC API EDR Part 1: V1.2 +++ /dev/null @@ -1 +0,0 @@ - From 9a4ee2bcfb8c7553d2dcbb6280d646f7f9c71548 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 19:23:25 +0100 Subject: [PATCH 22/34] Delete ogc-web-api-guidelines/OGC API EDR Part 2 Checklist V1.0 --- ogc-web-api-guidelines/OGC API EDR Part 2 Checklist V1.0 | 1 - 1 file changed, 1 deletion(-) delete mode 100644 ogc-web-api-guidelines/OGC API EDR Part 2 Checklist V1.0 diff --git a/ogc-web-api-guidelines/OGC API EDR Part 2 Checklist V1.0 b/ogc-web-api-guidelines/OGC API EDR Part 2 Checklist V1.0 deleted file mode 100644 index 8b1378917..000000000 --- a/ogc-web-api-guidelines/OGC API EDR Part 2 Checklist V1.0 +++ /dev/null @@ -1 +0,0 @@ - From 2c1786e437cf673f9952f4b9f6e5c3fe159d426e Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 19:23:45 +0100 Subject: [PATCH 23/34] Delete ogc-web-api-guidelines/OGC API EDR Part 2: PubSub --- ogc-web-api-guidelines/OGC API EDR Part 2: PubSub | 1 - 1 file changed, 1 deletion(-) delete mode 100644 ogc-web-api-guidelines/OGC API EDR Part 2: PubSub diff --git a/ogc-web-api-guidelines/OGC API EDR Part 2: PubSub b/ogc-web-api-guidelines/OGC API EDR Part 2: PubSub deleted file mode 100644 index 8b1378917..000000000 --- a/ogc-web-api-guidelines/OGC API EDR Part 2: PubSub +++ /dev/null @@ -1 +0,0 @@ - From 3f7b6a8c93d208ac24ded4144afe6e1b134e36fa Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 19:24:02 +0100 Subject: [PATCH 24/34] Delete ogc-web-api-guidelines/OGC API EDR V1.1 --- ogc-web-api-guidelines/OGC API EDR V1.1 | 1 - 1 file changed, 1 deletion(-) delete mode 100644 ogc-web-api-guidelines/OGC API EDR V1.1 diff --git a/ogc-web-api-guidelines/OGC API EDR V1.1 b/ogc-web-api-guidelines/OGC API EDR V1.1 deleted file mode 100644 index 8b1378917..000000000 --- a/ogc-web-api-guidelines/OGC API EDR V1.1 +++ /dev/null @@ -1 +0,0 @@ - From 4822bc7c4c375e8c9a5c5844e98d21e2f0e3b177 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 21:02:53 +0100 Subject: [PATCH 25/34] Update OGC API EDR Checklist V1.0 --- .../OGC API EDR Checklist V1.0 | 66 ++++++++++++------- 1 file changed, 41 insertions(+), 25 deletions(-) diff --git a/ogc-web-api-guidelines/OGC API EDR Checklist V1.0 b/ogc-web-api-guidelines/OGC API EDR Checklist V1.0 index adefb4688..ecceaa191 100644 --- a/ogc-web-api-guidelines/OGC API EDR Checklist V1.0 +++ b/ogc-web-api-guidelines/OGC API EDR Checklist V1.0 @@ -4,33 +4,49 @@ To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directive See an example in the [OGC API - Common - Part 1: Core Standard](https://docs.ogc.org/is/19-072/19-072.html#_c483b499-4a80-4d7d-997e-100e0d89a0b3). - - | # | Principle | Discussion | -- | -- | -- -| 1 | Don’t reinvent | -| 2 | Keep it simple and intuitive | -| 3 | Use well-known resource types | -| 4 | Construct consistent URIs | -| 5 | Use HTTP methods consistent with RFC 7231 | -| 6 | Put selection criteria behind the ‘?’ | -| 7 | Error handling and use of HTTP status codes | -| 8 | Use explicit list of HTTP status codes | -| 9 | Use of HTTP header | -| 10 | Allow flexible content negotiation | -| 11 | Pagination | -| 12 | Processing resources | -| 13 | Support metadata | -| 14 | Consider your security needs | -| 15 | API description | -| 16 | Use well-known identifiers | -| 17 | Use explicit relations | -| 18 | Support W3C cross-origin resource sharing | -| 19 | Resource encodings | -| 20 | Good APIs are testable from the beginning | -| 21 | Specify whether operations are safe and/or idempotent | -| 22 | Make resources discoverable | -| 23 | Make default behavior explicit | +| 1 | Don’t reinvent | adopts concepts from OGC API - Common (landing page, conformance, collections, datetime query parameter) and OGC API - Features (`/collections/{collectionId}/items`) and uses WKT and ISO8601 for most syntax +| 2 | Keep it simple and intuitive | - allows for minimal compliant implementation (1 query type) + - provides interaction with minimal domain knowledge + - provide query types as convenience / shortcuts to common subsetting patterns + +| 3 | Use well-known resource types | - provides a resource agnostic and inclusive API + - CoverageJSON resource type is `application/vnd.cov+json`. Another type may be registered with IANA if appropriate +| 4 | Construct consistent URIs | - adopts collection of resources principle + - `/collections/{collectionId}/items` + - `/collections/{collectionId}/{queryType}` +| 5 | Use HTTP methods consistent with RFC 7231 | - implements resource-based HTTP `GET` methods + - future work may add support for HTTP `POST` + - to help with URL truncation + - to help with security of sending sensitive data + - future work may add support for HTTP `OPTIONS`, required for CORS/preflight +| 6 | Put selection criteria behind the ‘?’ | - provides query parameter support in order to further subset a given resource/query type +| 7 | Error handling and use of HTTP status codes | - provides exception schema (code and description) as well as the appropriate HTTP status codes +| 8 | Use explicit list of HTTP status codes | - 200, 202, 204, 304, 308, 400, 401, 403, 404, 405, 406, 413, 500 (see Table 6) +| 9 | Use of HTTP header | - allows for Link headers +| 10 | Allow flexible content negotiation | - currently not addressed +| 11 | Pagination | - eliminates pagination given the design patterns of the query types to provide succinct results from discrete sampling +| 12 | Processing resources | - Not applicable +| 13 | Support metadata | - provides `service-desc` and `service-doc` link relations + - provides metadata via extended collections model +| 14 | Consider your security needs | - supports HTTPS (See 6.6) and RFC2818 + - it is recommended to explicitly NOT support HTTP, addressing + - privacy issues + - insecure communication + - it is recommended that HTTP `POST` is used as an additional security mechanism +| 15 | API description | - supports OpenAPI for API documentation +| 16 | Use well-known identifiers | - provides media types and link relations that are based on IANA and extended per the OGC Definitions Server +| 17 | Use explicit relations | - The primary function is query and a single response. Links to associated resources describing the query response are explicit (have we got there yet?) + +| 18 | Support W3C cross-origin resource sharing | - CORS is supported (See 10.4) +| 19 | Resource encodings | - supports JSON, GeoJSON, HTML and CoverageJSON +| 20 | Good APIs are testable from the beginning | - demonstrates this via the EDR ETS + - enables standard programming libraries in implementing standard HTTP request/response, headers and well-known media types and design patterns +| 21 | Specify whether operations are safe and/or idempotent | - provides both safe and idempotent operations via HTTP `GET` +| 22 | Make resources discoverable | - implements common OGC API link relations +| 23 | Make default behavior explicit | - collection metadata provides the ability for link relations via URL templates along with explanations of templated variables + - example: https://github.com/opengeospatial/ogcapi-environmental-data-retrieval/blob/master/candidate-standard/examples/collections_metadata_JSON_1.adoc ## OGC API - Environmental Data Retrieval - Part 2: Publish-Subscribe Workflows (version-number) From 7e4582147a17d1aa42ab54d80de5f96042e431b7 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 21:06:46 +0100 Subject: [PATCH 26/34] Update OGC API EDR Checklist V1.0 --- .../OGC API EDR Checklist V1.0 | 79 ++++++------------- 1 file changed, 22 insertions(+), 57 deletions(-) diff --git a/ogc-web-api-guidelines/OGC API EDR Checklist V1.0 b/ogc-web-api-guidelines/OGC API EDR Checklist V1.0 index ecceaa191..7cafb52a3 100644 --- a/ogc-web-api-guidelines/OGC API EDR Checklist V1.0 +++ b/ogc-web-api-guidelines/OGC API EDR Checklist V1.0 @@ -7,78 +7,43 @@ See an example in the [OGC API - Common - Part 1: Core Standard](https://docs.og | # | Principle | Discussion | -- | -- | -- | 1 | Don’t reinvent | adopts concepts from OGC API - Common (landing page, conformance, collections, datetime query parameter) and OGC API - Features (`/collections/{collectionId}/items`) and uses WKT and ISO8601 for most syntax -| 2 | Keep it simple and intuitive | - allows for minimal compliant implementation (1 query type) +| 2 | Keep it simple and intuitive | allows for minimal compliant implementation (1 query type) - provides interaction with minimal domain knowledge - provide query types as convenience / shortcuts to common subsetting patterns - -| 3 | Use well-known resource types | - provides a resource agnostic and inclusive API +| 3 | Use well-known resource types | provides a resource agnostic and inclusive API - CoverageJSON resource type is `application/vnd.cov+json`. Another type may be registered with IANA if appropriate -| 4 | Construct consistent URIs | - adopts collection of resources principle +| 4 | Construct consistent URIs | adopts collection of resources principle - `/collections/{collectionId}/items` - `/collections/{collectionId}/{queryType}` -| 5 | Use HTTP methods consistent with RFC 7231 | - implements resource-based HTTP `GET` methods +| 5 | Use HTTP methods consistent with RFC 7231 | implements resource-based HTTP `GET` methods - future work may add support for HTTP `POST` - to help with URL truncation - to help with security of sending sensitive data - future work may add support for HTTP `OPTIONS`, required for CORS/preflight -| 6 | Put selection criteria behind the ‘?’ | - provides query parameter support in order to further subset a given resource/query type -| 7 | Error handling and use of HTTP status codes | - provides exception schema (code and description) as well as the appropriate HTTP status codes -| 8 | Use explicit list of HTTP status codes | - 200, 202, 204, 304, 308, 400, 401, 403, 404, 405, 406, 413, 500 (see Table 6) -| 9 | Use of HTTP header | - allows for Link headers -| 10 | Allow flexible content negotiation | - currently not addressed -| 11 | Pagination | - eliminates pagination given the design patterns of the query types to provide succinct results from discrete sampling -| 12 | Processing resources | - Not applicable -| 13 | Support metadata | - provides `service-desc` and `service-doc` link relations +| 6 | Put selection criteria behind the ‘?’ | provides query parameter support in order to further subset a given resource/query type +| 7 | Error handling and use of HTTP status codes | provides exception schema (code and description) as well as the appropriate HTTP status codes +| 8 | Use explicit list of HTTP status codes | 200, 202, 204, 304, 308, 400, 401, 403, 404, 405, 406, 413, 500 (see Table 6) +| 9 | Use of HTTP header | allows for Link headers +| 10 | Allow flexible content negotiation | currently not addressed +| 11 | Pagination | eliminates pagination given the design patterns of the query types to provide succinct results from discrete sampling +| 12 | Processing resources | Not applicable +| 13 | Support metadata | provides `service-desc` and `service-doc` link relations - provides metadata via extended collections model -| 14 | Consider your security needs | - supports HTTPS (See 6.6) and RFC2818 +| 14 | Consider your security needs | supports HTTPS (See 6.6) and RFC2818 - it is recommended to explicitly NOT support HTTP, addressing - privacy issues - insecure communication - it is recommended that HTTP `POST` is used as an additional security mechanism -| 15 | API description | - supports OpenAPI for API documentation -| 16 | Use well-known identifiers | - provides media types and link relations that are based on IANA and extended per the OGC Definitions Server -| 17 | Use explicit relations | - The primary function is query and a single response. Links to associated resources describing the query response are explicit (have we got there yet?) - -| 18 | Support W3C cross-origin resource sharing | - CORS is supported (See 10.4) -| 19 | Resource encodings | - supports JSON, GeoJSON, HTML and CoverageJSON -| 20 | Good APIs are testable from the beginning | - demonstrates this via the EDR ETS +| 15 | API description | supports OpenAPI for API documentation +| 16 | Use well-known identifiers | provides media types and link relations that are based on IANA and extended per the OGC Definitions Server +| 17 | Use explicit relations | The primary function is query and a single response. Links to associated resources describing the query response are explicit (have we got there yet?) +| 18 | Support W3C cross-origin resource sharing | CORS is supported (See 10.4) +| 19 | Resource encodings | supports JSON, GeoJSON, HTML and CoverageJSON +| 20 | Good APIs are testable from the beginning | demonstrates this via the EDR ETS - enables standard programming libraries in implementing standard HTTP request/response, headers and well-known media types and design patterns -| 21 | Specify whether operations are safe and/or idempotent | - provides both safe and idempotent operations via HTTP `GET` -| 22 | Make resources discoverable | - implements common OGC API link relations -| 23 | Make default behavior explicit | - collection metadata provides the ability for link relations via URL templates along with explanations of templated variables +| 21 | Specify whether operations are safe and/or idempotent | provides both safe and idempotent operations via HTTP `GET` +| 22 | Make resources discoverable | implements common OGC API link relations +| 23 | Make default behavior explicit | collection metadata provides the ability for link relations via URL templates along with explanations of templated variables - example: https://github.com/opengeospatial/ogcapi-environmental-data-retrieval/blob/master/candidate-standard/examples/collections_metadata_JSON_1.adoc -## OGC API - Environmental Data Retrieval - Part 2: Publish-Subscribe Workflows (version-number) - -To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. - -See an example on the [OGC-Web-API-Guidelines](https://github.com/opengeospatial/OGC-Web-API-Guidelines/blob/master/Examples/API-Common-Core_api_guidelines.adoc) repo. - - -| # | Principle | Discussion -| -- | -- | -- -| 1 | Don’t reinvent | -| 2 | Keep it simple and intuitive | -| 3 | Use well-known resource types | -| 4 | Construct consistent URIs | -| 5 | Use HTTP methods consistent with RFC 7231 | -| 6 | Put selection criteria behind the ‘?’ | -| 7 | Error handling and use of HTTP status codes | -| 8 | Use explicit list of HTTP status codes | -| 9 | Use of HTTP header | -| 10 | Allow flexible content negotiation | -| 11 | Pagination | -| 12 | Processing resources | -| 13 | Support metadata | -| 14 | Consider your security needs | -| 15 | API description | -| 16 | Use well-known identifiers | -| 17 | Use explicit relations | -| 18 | Support W3C cross-origin resource sharing | -| 19 | Resource encodings | -| 20 | Good APIs are testable from the beginning | -| 21 | Specify whether operations are safe and/or idempotent | -| 22 | Make resources discoverable | -| 23 | Make default behavior explicit | - From 4a2582485a895c5f32742238a8fd0ee7e503042e Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 21:08:28 +0100 Subject: [PATCH 27/34] Delete ogc-web-api-guidelines-checklist.md --- ogc-web-api-guidelines-checklist.md | 68 ----------------------------- 1 file changed, 68 deletions(-) delete mode 100644 ogc-web-api-guidelines-checklist.md diff --git a/ogc-web-api-guidelines-checklist.md b/ogc-web-api-guidelines-checklist.md deleted file mode 100644 index ecad27188..000000000 --- a/ogc-web-api-guidelines-checklist.md +++ /dev/null @@ -1,68 +0,0 @@ -# OGC EDR API Support of OGC Web API Guidelines - -# Overview - -This document outlines EDR API support of the design principles of the [OGC Web API Guidelines](https://github.com/opengeospatial/OGC-Web-API-Guidelines). - -- [x] Principle #1 – Don’t Reinvent - - adopts concepts from OGC API - Common (landing page, conformance, collections, datetime query parameter) and OGC API - Features (`/collections/{collectionId}/items`) and uses WKT and ISO8601 for most syntax -- [x] Principle #2 – Keep the API Simple and Intuitive - - allows for minimal compliant implementation (1 query type) - - provides interaction with minimal domain knowledge - - provide query types as convenience / shortcuts to common subsetting patterns -- [x] Principle #3 - Use Well-Known Resource Types - - provides a resource agnostic and inclusive API - - CoverageJSON resource type is `application/vnd.cov+json`. Another type may be registered with IANA if appropriate -- [x] Principle #4 – Construct consistent URIs - - adopts collection of resources principle - - `/collections/{collectionId}/items` - - `/collections/{collectionId}/{queryType}` -- [x] Principle #5 – Use HTTP Methods consistent with RFC 7231 - - implements resource-based HTTP `GET` methods - - future work may add support for HTTP `POST` - - to help with URL truncation - - to help with security of sending sensitive data - - future work may add support for HTTP `OPTIONS`, required for CORS/preflight -- [x] Principle #6 – Put Selection Criteria behind the ‘?’ - - provides query parameter support in order to further subset a given resource/query type -- [x] Principle #7 – Error Handling and use of HTTP Status Codes - - provides exception schema (code and description) as well as the appropriate HTTP status codes -- [x] Principle #8 – Use explicit list of HTTP Status Codes - - 200, 202, 204, 304, 308, 400, 401, 403, 404, 405, 406, 413, 500 (see Table 6) -- [x] Principle #9 – Use of HTTP Header - - allows for Link headers -- [ ] Principle #10 - Allow flexible Content Negotiation - - currently not addressed -- [ ] Principle #11 - Pagination - - eliminates pagination given the design patterns of the query types to provide succinct results from discrete sampling -- [ ] Principle #12 – Processing Resources - - Not applicable -- [x] Principle #13 – Support Metadata - - provides `service-desc` and `service-doc` link relations - - provides metadata via extended collections model -- [x] Principle #14 – Consider your Security needs - - supports HTTPS (See 6.6) and RFC2818 - - it is recommended to explicitly NOT support HTTP, addressing - - privacy issues - - insecure communication - - it is recommended that HTTP `POST` is used as an additional security mechanism -- [x] Principle #15 – API Description - - supports OpenAPI for API documentation -- [x] Principle #16 - Use well-known identifiers - - provides media types and link relations that are based on IANA and extended per the OGC Definitions Server -- [x] Principle #17 - Use explicit relations - - The primary function is query and a single response. Links to associated resources describing the query response are explicit (have we got there yet?) -- [x] Principle #18 - Support W3C Cross-Origin Resource Sharing - - CORS is supported (See 10.4) -- [x] Principle #19 - Resource encodings - - supports JSON, GeoJSON, HTML and CoverageJSON -- [x] Principle #20 - Good APIs are testable from the beginning - - demonstrates this via the EDR ETS - - enables standard programming libraries in implementing standard HTTP request/response, headers and well-known media types and design patterns -- [x] Principle #21 - Specify whether operations are safe and/or idempotent - - provides both safe and idempotent operations via HTTP `GET` -- [x] Principle #22 – Make resources discoverable - - implements common OGC API link relations -- [x] Principle #23 - Make default behavior explicit - - collection metadata provides the ability for link relations via URL templates along with explanations of templated variables - - example: https://github.com/opengeospatial/ogcapi-environmental-data-retrieval/blob/master/candidate-standard/examples/collections_metadata_JSON_1.adoc From eec3b96cd9b77ea9ac8d30441a55034300e0963f Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 21:19:06 +0100 Subject: [PATCH 28/34] Create OGC API EDR Checklist V1.0.md --- .../OGC API EDR Checklist V1.0.md | 31 +++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 ogc-web-api-guidelines/OGC API EDR Checklist V1.0.md diff --git a/ogc-web-api-guidelines/OGC API EDR Checklist V1.0.md b/ogc-web-api-guidelines/OGC API EDR Checklist V1.0.md new file mode 100644 index 000000000..da26980a3 --- /dev/null +++ b/ogc-web-api-guidelines/OGC API EDR Checklist V1.0.md @@ -0,0 +1,31 @@ +## OGC API - Environmental Data Retrieval Version 1.0 + +To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. + +See an example in the [OGC API - Common - Part 1: Core Standard](https://docs.ogc.org/is/19-072/19-072.html#_c483b499-4a80-4d7d-997e-100e0d89a0b3). + +| # | Principle | Discussion +| -- | -- | -- +| 1 | Don’t reinvent | adopts concepts from OGC API - Common (landing page, conformance, collections, datetime query parameter) and OGC API - Features (`/collections/{collectionId}/items`) and uses WKT and ISO8601 for most syntax +| 2 | Keep it simple and intuitive | allows for minimal compliant implementation (1 query type) - provides interaction with minimal domain knowledge - provide query types as convenience / shortcuts to common subsetting patterns +| 3 | Use well-known resource types | provides a resource agnostic and inclusive API - CoverageJSON resource type is `application/vnd.cov+json`. Another type may be registered with IANA if appropriate +| 4 | Construct consistent URIs | adopts collection of resources principle - `/collections/{collectionId}/items` - `/collections/{collectionId}/{queryType}` +| 5 | Use HTTP methods consistent with RFC 7231 | implements resource-based HTTP `GET` methods - future work may add support for HTTP `POST` - to help with URL truncation - to help with security of sending sensitive data - future work may add support for HTTP `OPTIONS`, required for CORS/preflight +| 6 | Put selection criteria behind the ‘?’ | provides query parameter support in order to further subset a given resource/query type +| 7 | Error handling and use of HTTP status codes | provides exception schema (code and description) as well as the appropriate HTTP status codes +| 8 | Use explicit list of HTTP status codes | 200, 202, 204, 304, 308, 400, 401, 403, 404, 405, 406, 413, 500 (see Table 6) +| 9 | Use of HTTP header | allows for Link headers +| 10 | Allow flexible content negotiation | currently not addressed +| 11 | Pagination | eliminates pagination given the design patterns of the query types to provide succinct results from discrete sampling +| 12 | Processing resources | Not applicable +| 13 | Support metadata | provides `service-desc` and `service-doc` link relations - provides metadata via extended collections model +| 14 | Consider your security needs | supports HTTPS (See 6.6) and RFC2818 - it is recommended to explicitly NOT support HTTP, addressing - privacy issues - insecure communication - it is recommended that HTTP `POST` is used as an additional security mechanism +| 15 | API description | supports OpenAPI for API documentation +| 16 | Use well-known identifiers | provides media types and link relations that are based on IANA and extended per the OGC Definitions Server +| 17 | Use explicit relations | The primary function is query and a single response. Links to associated resources describing the query response are explicit (have we got there yet?) +| 18 | Support W3C cross-origin resource sharing | CORS is supported (See 10.4) +| 19 | Resource encodings | supports JSON, GeoJSON, HTML and CoverageJSON +| 20 | Good APIs are testable from the beginning | demonstrates this via the EDR ETS - enables standard programming libraries in implementing standard HTTP request/response, headers and well-known media types and design patterns +| 21 | Specify whether operations are safe and/or idempotent | provides both safe and idempotent operations via HTTP `GET` +| 22 | Make resources discoverable | implements common OGC API link relations +| 23 | Make default behavior explicit | collection metadata provides the ability for link relations via URL templates along with explanations of templated variables - example: https://github.com/opengeospatial/ogcapi-environmental-data-retrieval/blob/master/candidate-standard/examples/collections_metadata_JSON_1.adoc From f5e6865e66f20350942e879ecdba6111ff6f565d Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 21:19:28 +0100 Subject: [PATCH 29/34] Delete ogc-web-api-guidelines/OGC API EDR Checklist V1.0 --- .../OGC API EDR Checklist V1.0 | 49 ------------------- 1 file changed, 49 deletions(-) delete mode 100644 ogc-web-api-guidelines/OGC API EDR Checklist V1.0 diff --git a/ogc-web-api-guidelines/OGC API EDR Checklist V1.0 b/ogc-web-api-guidelines/OGC API EDR Checklist V1.0 deleted file mode 100644 index 7cafb52a3..000000000 --- a/ogc-web-api-guidelines/OGC API EDR Checklist V1.0 +++ /dev/null @@ -1,49 +0,0 @@ -## OGC API - Environmental Data Retrieval Version 1.0 - -To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. - -See an example in the [OGC API - Common - Part 1: Core Standard](https://docs.ogc.org/is/19-072/19-072.html#_c483b499-4a80-4d7d-997e-100e0d89a0b3). - -| # | Principle | Discussion -| -- | -- | -- -| 1 | Don’t reinvent | adopts concepts from OGC API - Common (landing page, conformance, collections, datetime query parameter) and OGC API - Features (`/collections/{collectionId}/items`) and uses WKT and ISO8601 for most syntax -| 2 | Keep it simple and intuitive | allows for minimal compliant implementation (1 query type) - - provides interaction with minimal domain knowledge - - provide query types as convenience / shortcuts to common subsetting patterns -| 3 | Use well-known resource types | provides a resource agnostic and inclusive API - - CoverageJSON resource type is `application/vnd.cov+json`. Another type may be registered with IANA if appropriate -| 4 | Construct consistent URIs | adopts collection of resources principle - - `/collections/{collectionId}/items` - - `/collections/{collectionId}/{queryType}` -| 5 | Use HTTP methods consistent with RFC 7231 | implements resource-based HTTP `GET` methods - - future work may add support for HTTP `POST` - - to help with URL truncation - - to help with security of sending sensitive data - - future work may add support for HTTP `OPTIONS`, required for CORS/preflight -| 6 | Put selection criteria behind the ‘?’ | provides query parameter support in order to further subset a given resource/query type -| 7 | Error handling and use of HTTP status codes | provides exception schema (code and description) as well as the appropriate HTTP status codes -| 8 | Use explicit list of HTTP status codes | 200, 202, 204, 304, 308, 400, 401, 403, 404, 405, 406, 413, 500 (see Table 6) -| 9 | Use of HTTP header | allows for Link headers -| 10 | Allow flexible content negotiation | currently not addressed -| 11 | Pagination | eliminates pagination given the design patterns of the query types to provide succinct results from discrete sampling -| 12 | Processing resources | Not applicable -| 13 | Support metadata | provides `service-desc` and `service-doc` link relations - - provides metadata via extended collections model -| 14 | Consider your security needs | supports HTTPS (See 6.6) and RFC2818 - - it is recommended to explicitly NOT support HTTP, addressing - - privacy issues - - insecure communication - - it is recommended that HTTP `POST` is used as an additional security mechanism -| 15 | API description | supports OpenAPI for API documentation -| 16 | Use well-known identifiers | provides media types and link relations that are based on IANA and extended per the OGC Definitions Server -| 17 | Use explicit relations | The primary function is query and a single response. Links to associated resources describing the query response are explicit (have we got there yet?) -| 18 | Support W3C cross-origin resource sharing | CORS is supported (See 10.4) -| 19 | Resource encodings | supports JSON, GeoJSON, HTML and CoverageJSON -| 20 | Good APIs are testable from the beginning | demonstrates this via the EDR ETS - - enables standard programming libraries in implementing standard HTTP request/response, headers and well-known media types and design patterns -| 21 | Specify whether operations are safe and/or idempotent | provides both safe and idempotent operations via HTTP `GET` -| 22 | Make resources discoverable | implements common OGC API link relations -| 23 | Make default behavior explicit | collection metadata provides the ability for link relations via URL templates along with explanations of templated variables - - example: https://github.com/opengeospatial/ogcapi-environmental-data-retrieval/blob/master/candidate-standard/examples/collections_metadata_JSON_1.adoc - - From d2c0dc86364ae214436e1e9162fd9e8bfb22244b Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 21:22:33 +0100 Subject: [PATCH 30/34] Create OGC API EDR Checklist V1.1.md --- .../OGC API EDR Checklist V1.1.md | 35 +++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 ogc-web-api-guidelines/OGC API EDR Checklist V1.1.md diff --git a/ogc-web-api-guidelines/OGC API EDR Checklist V1.1.md b/ogc-web-api-guidelines/OGC API EDR Checklist V1.1.md new file mode 100644 index 000000000..3c3fec4e5 --- /dev/null +++ b/ogc-web-api-guidelines/OGC API EDR Checklist V1.1.md @@ -0,0 +1,35 @@ +## OGC API - Environmental Data Retrieval Version 1.1 + +To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. + +See an example in the [OGC API - Common - Part 1: Core Standard](https://docs.ogc.org/is/19-072/19-072.html#_c483b499-4a80-4d7d-997e-100e0d89a0b3). + + + +| # | Principle | Discussion +| -- | -- | -- +| 1 | Don’t reinvent | +| 2 | Keep it simple and intuitive | +| 3 | Use well-known resource types | +| 4 | Construct consistent URIs | +| 5 | Use HTTP methods consistent with RFC 7231 | +| 6 | Put selection criteria behind the ‘?’ | +| 7 | Error handling and use of HTTP status codes | +| 8 | Use explicit list of HTTP status codes | +| 9 | Use of HTTP header | +| 10 | Allow flexible content negotiation | +| 11 | Pagination | +| 12 | Processing resources | +| 13 | Support metadata | +| 14 | Consider your security needs | +| 15 | API description | +| 16 | Use well-known identifiers | +| 17 | Use explicit relations | +| 18 | Support W3C cross-origin resource sharing | +| 19 | Resource encodings | +| 20 | Good APIs are testable from the beginning | +| 21 | Specify whether operations are safe and/or idempotent | +| 22 | Make resources discoverable | +| 23 | Make default behavior explicit | + + From 662ce20cafa195b40583297933efcf8195034f6c Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 21:22:51 +0100 Subject: [PATCH 31/34] Delete ogc-web-api-guidelines/OGC API EDR Checklist V1.1 --- .../OGC API EDR Checklist V1.1 | 68 ------------------- 1 file changed, 68 deletions(-) delete mode 100644 ogc-web-api-guidelines/OGC API EDR Checklist V1.1 diff --git a/ogc-web-api-guidelines/OGC API EDR Checklist V1.1 b/ogc-web-api-guidelines/OGC API EDR Checklist V1.1 deleted file mode 100644 index d2e589b70..000000000 --- a/ogc-web-api-guidelines/OGC API EDR Checklist V1.1 +++ /dev/null @@ -1,68 +0,0 @@ -## OGC API - Environmental Data Retrieval Version 1.1 - -To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. - -See an example in the [OGC API - Common - Part 1: Core Standard](https://docs.ogc.org/is/19-072/19-072.html#_c483b499-4a80-4d7d-997e-100e0d89a0b3). - - - -| # | Principle | Discussion -| -- | -- | -- -| 1 | Don’t reinvent | -| 2 | Keep it simple and intuitive | -| 3 | Use well-known resource types | -| 4 | Construct consistent URIs | -| 5 | Use HTTP methods consistent with RFC 7231 | -| 6 | Put selection criteria behind the ‘?’ | -| 7 | Error handling and use of HTTP status codes | -| 8 | Use explicit list of HTTP status codes | -| 9 | Use of HTTP header | -| 10 | Allow flexible content negotiation | -| 11 | Pagination | -| 12 | Processing resources | -| 13 | Support metadata | -| 14 | Consider your security needs | -| 15 | API description | -| 16 | Use well-known identifiers | -| 17 | Use explicit relations | -| 18 | Support W3C cross-origin resource sharing | -| 19 | Resource encodings | -| 20 | Good APIs are testable from the beginning | -| 21 | Specify whether operations are safe and/or idempotent | -| 22 | Make resources discoverable | -| 23 | Make default behavior explicit | - - -## OGC API - Environmental Data Retrieval - Part 2: Publish-Subscribe Workflows (version-number) - -To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. - -See an example on the [OGC-Web-API-Guidelines](https://github.com/opengeospatial/OGC-Web-API-Guidelines/blob/master/Examples/API-Common-Core_api_guidelines.adoc) repo. - - -| # | Principle | Discussion -| -- | -- | -- -| 1 | Don’t reinvent | -| 2 | Keep it simple and intuitive | -| 3 | Use well-known resource types | -| 4 | Construct consistent URIs | -| 5 | Use HTTP methods consistent with RFC 7231 | -| 6 | Put selection criteria behind the ‘?’ | -| 7 | Error handling and use of HTTP status codes | -| 8 | Use explicit list of HTTP status codes | -| 9 | Use of HTTP header | -| 10 | Allow flexible content negotiation | -| 11 | Pagination | -| 12 | Processing resources | -| 13 | Support metadata | -| 14 | Consider your security needs | -| 15 | API description | -| 16 | Use well-known identifiers | -| 17 | Use explicit relations | -| 18 | Support W3C cross-origin resource sharing | -| 19 | Resource encodings | -| 20 | Good APIs are testable from the beginning | -| 21 | Specify whether operations are safe and/or idempotent | -| 22 | Make resources discoverable | -| 23 | Make default behavior explicit | - From d47873cacee1c64d4afcbfe7dc5628bff20992ed Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 21:25:33 +0100 Subject: [PATCH 32/34] Create OGC API EDR Part 1 Core Checklist V1.2.md --- .../OGC API EDR Part 1 Core Checklist V1.2.md | 34 +++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 ogc-web-api-guidelines/OGC API EDR Part 1 Core Checklist V1.2.md diff --git a/ogc-web-api-guidelines/OGC API EDR Part 1 Core Checklist V1.2.md b/ogc-web-api-guidelines/OGC API EDR Part 1 Core Checklist V1.2.md new file mode 100644 index 000000000..736206396 --- /dev/null +++ b/ogc-web-api-guidelines/OGC API EDR Part 1 Core Checklist V1.2.md @@ -0,0 +1,34 @@ +## OGC API - Environmental Data Retrieval Part 1: Core Version 1.2 + +To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. + +See an example in the [OGC API - Common - Part 1: Core Standard](https://docs.ogc.org/is/19-072/19-072.html#_c483b499-4a80-4d7d-997e-100e0d89a0b3). + + + +| # | Principle | Discussion +| -- | -- | -- +| 1 | Don’t reinvent | +| 2 | Keep it simple and intuitive | +| 3 | Use well-known resource types | +| 4 | Construct consistent URIs | +| 5 | Use HTTP methods consistent with RFC 7231 | +| 6 | Put selection criteria behind the ‘?’ | +| 7 | Error handling and use of HTTP status codes | +| 8 | Use explicit list of HTTP status codes | +| 9 | Use of HTTP header | +| 10 | Allow flexible content negotiation | +| 11 | Pagination | +| 12 | Processing resources | +| 13 | Support metadata | +| 14 | Consider your security needs | +| 15 | API description | +| 16 | Use well-known identifiers | +| 17 | Use explicit relations | +| 18 | Support W3C cross-origin resource sharing | +| 19 | Resource encodings | +| 20 | Good APIs are testable from the beginning | +| 21 | Specify whether operations are safe and/or idempotent | +| 22 | Make resources discoverable | +| 23 | Make default behavior explicit | + From 422322bb7fdc569f4d1f96b12ff52d01c2a721eb Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 21:25:52 +0100 Subject: [PATCH 33/34] Delete ogc-web-api-guidelines/OGC API EDR Part 1 Core Checklist V1.2 --- .../OGC API EDR Part 1 Core Checklist V1.2 | 68 ------------------- 1 file changed, 68 deletions(-) delete mode 100644 ogc-web-api-guidelines/OGC API EDR Part 1 Core Checklist V1.2 diff --git a/ogc-web-api-guidelines/OGC API EDR Part 1 Core Checklist V1.2 b/ogc-web-api-guidelines/OGC API EDR Part 1 Core Checklist V1.2 deleted file mode 100644 index 4ad9675a3..000000000 --- a/ogc-web-api-guidelines/OGC API EDR Part 1 Core Checklist V1.2 +++ /dev/null @@ -1,68 +0,0 @@ -## OGC API - Environmental Data Retrieval Part 1: Core Version 1.2 - -To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. - -See an example in the [OGC API - Common - Part 1: Core Standard](https://docs.ogc.org/is/19-072/19-072.html#_c483b499-4a80-4d7d-997e-100e0d89a0b3). - - - -| # | Principle | Discussion -| -- | -- | -- -| 1 | Don’t reinvent | -| 2 | Keep it simple and intuitive | -| 3 | Use well-known resource types | -| 4 | Construct consistent URIs | -| 5 | Use HTTP methods consistent with RFC 7231 | -| 6 | Put selection criteria behind the ‘?’ | -| 7 | Error handling and use of HTTP status codes | -| 8 | Use explicit list of HTTP status codes | -| 9 | Use of HTTP header | -| 10 | Allow flexible content negotiation | -| 11 | Pagination | -| 12 | Processing resources | -| 13 | Support metadata | -| 14 | Consider your security needs | -| 15 | API description | -| 16 | Use well-known identifiers | -| 17 | Use explicit relations | -| 18 | Support W3C cross-origin resource sharing | -| 19 | Resource encodings | -| 20 | Good APIs are testable from the beginning | -| 21 | Specify whether operations are safe and/or idempotent | -| 22 | Make resources discoverable | -| 23 | Make default behavior explicit | - - -## OGC API - Environmental Data Retrieval - Part 2: Publish-Subscribe Workflows (version-number) - -To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. - -See an example on the [OGC-Web-API-Guidelines](https://github.com/opengeospatial/OGC-Web-API-Guidelines/blob/master/Examples/API-Common-Core_api_guidelines.adoc) repo. - - -| # | Principle | Discussion -| -- | -- | -- -| 1 | Don’t reinvent | -| 2 | Keep it simple and intuitive | -| 3 | Use well-known resource types | -| 4 | Construct consistent URIs | -| 5 | Use HTTP methods consistent with RFC 7231 | -| 6 | Put selection criteria behind the ‘?’ | -| 7 | Error handling and use of HTTP status codes | -| 8 | Use explicit list of HTTP status codes | -| 9 | Use of HTTP header | -| 10 | Allow flexible content negotiation | -| 11 | Pagination | -| 12 | Processing resources | -| 13 | Support metadata | -| 14 | Consider your security needs | -| 15 | API description | -| 16 | Use well-known identifiers | -| 17 | Use explicit relations | -| 18 | Support W3C cross-origin resource sharing | -| 19 | Resource encodings | -| 20 | Good APIs are testable from the beginning | -| 21 | Specify whether operations are safe and/or idempotent | -| 22 | Make resources discoverable | -| 23 | Make default behavior explicit | - From 94e86d5d6f04730a532e2d0f253fd5890e755a09 Mon Sep 17 00:00:00 2001 From: Chris Little Date: Tue, 11 Jun 2024 21:29:00 +0100 Subject: [PATCH 34/34] Update and rename OGC API EDR Part 2 PubSub Checklist V1.0 to OGC API EDR Part 2 PubSub Checklist V1.0.md --- .../OGC API EDR Part 2 PubSub Checklist V1.0 | 68 ------------------- ...GC API EDR Part 2 PubSub Checklist V1.0.md | 36 ++++++++++ 2 files changed, 36 insertions(+), 68 deletions(-) delete mode 100644 ogc-web-api-guidelines/OGC API EDR Part 2 PubSub Checklist V1.0 create mode 100644 ogc-web-api-guidelines/OGC API EDR Part 2 PubSub Checklist V1.0.md diff --git a/ogc-web-api-guidelines/OGC API EDR Part 2 PubSub Checklist V1.0 b/ogc-web-api-guidelines/OGC API EDR Part 2 PubSub Checklist V1.0 deleted file mode 100644 index cfc551840..000000000 --- a/ogc-web-api-guidelines/OGC API EDR Part 2 PubSub Checklist V1.0 +++ /dev/null @@ -1,68 +0,0 @@ -## OGC API - Environmental Data Retrieval Part 2: Publish-Subscribe Version 1.0 - -To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. - -See an example in the [OGC API - Common - Part 1: Core Standard](https://docs.ogc.org/is/19-072/19-072.html#_c483b499-4a80-4d7d-997e-100e0d89a0b3). - - - -| # | Principle | Discussion -| -- | -- | -- -| 1 | Don’t reinvent | -| 2 | Keep it simple and intuitive | -| 3 | Use well-known resource types | -| 4 | Construct consistent URIs | -| 5 | Use HTTP methods consistent with RFC 7231 | -| 6 | Put selection criteria behind the ‘?’ | -| 7 | Error handling and use of HTTP status codes | -| 8 | Use explicit list of HTTP status codes | -| 9 | Use of HTTP header | -| 10 | Allow flexible content negotiation | -| 11 | Pagination | -| 12 | Processing resources | -| 13 | Support metadata | -| 14 | Consider your security needs | -| 15 | API description | -| 16 | Use well-known identifiers | -| 17 | Use explicit relations | -| 18 | Support W3C cross-origin resource sharing | -| 19 | Resource encodings | -| 20 | Good APIs are testable from the beginning | -| 21 | Specify whether operations are safe and/or idempotent | -| 22 | Make resources discoverable | -| 23 | Make default behavior explicit | - - -## OGC API - Environmental Data Retrieval - Part 2: Publish-Subscribe Workflows (version-number) - -To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. - -See an example on the [OGC-Web-API-Guidelines](https://github.com/opengeospatial/OGC-Web-API-Guidelines/blob/master/Examples/API-Common-Core_api_guidelines.adoc) repo. - - -| # | Principle | Discussion -| -- | -- | -- -| 1 | Don’t reinvent | -| 2 | Keep it simple and intuitive | -| 3 | Use well-known resource types | -| 4 | Construct consistent URIs | -| 5 | Use HTTP methods consistent with RFC 7231 | -| 6 | Put selection criteria behind the ‘?’ | -| 7 | Error handling and use of HTTP status codes | -| 8 | Use explicit list of HTTP status codes | -| 9 | Use of HTTP header | -| 10 | Allow flexible content negotiation | -| 11 | Pagination | -| 12 | Processing resources | -| 13 | Support metadata | -| 14 | Consider your security needs | -| 15 | API description | -| 16 | Use well-known identifiers | -| 17 | Use explicit relations | -| 18 | Support W3C cross-origin resource sharing | -| 19 | Resource encodings | -| 20 | Good APIs are testable from the beginning | -| 21 | Specify whether operations are safe and/or idempotent | -| 22 | Make resources discoverable | -| 23 | Make default behavior explicit | - diff --git a/ogc-web-api-guidelines/OGC API EDR Part 2 PubSub Checklist V1.0.md b/ogc-web-api-guidelines/OGC API EDR Part 2 PubSub Checklist V1.0.md new file mode 100644 index 000000000..0b117ae34 --- /dev/null +++ b/ogc-web-api-guidelines/OGC API EDR Part 2 PubSub Checklist V1.0.md @@ -0,0 +1,36 @@ +## OGC API - Environmental Data Retrieval Part 2: Publish-Subscribe Workflows Version 1.0 + +To comply with [Policy Directive 50](https://portal.ogc.org/public_ogc/directives/directives.php#50), the following should be completed. + +See an example in the [OGC API - Common - Part 1: Core Standard](https://docs.ogc.org/is/19-072/19-072.html#_c483b499-4a80-4d7d-997e-100e0d89a0b3). + + + +| # | Principle | Discussion +| -- | -- | -- +| 1 | Don’t reinvent | +| 2 | Keep it simple and intuitive | +| 3 | Use well-known resource types | +| 4 | Construct consistent URIs | +| 5 | Use HTTP methods consistent with RFC 7231 | +| 6 | Put selection criteria behind the ‘?’ | +| 7 | Error handling and use of HTTP status codes | +| 8 | Use explicit list of HTTP status codes | +| 9 | Use of HTTP header | +| 10 | Allow flexible content negotiation | +| 11 | Pagination | +| 12 | Processing resources | +| 13 | Support metadata | +| 14 | Consider your security needs | +| 15 | API description | +| 16 | Use well-known identifiers | +| 17 | Use explicit relations | +| 18 | Support W3C cross-origin resource sharing | +| 19 | Resource encodings | +| 20 | Good APIs are testable from the beginning | +| 21 | Specify whether operations are safe and/or idempotent | +| 22 | Make resources discoverable | +| 23 | Make default behavior explicit | + + +