Compliance to OGC Web API Guidelines - opengeospatial/ogcapi-processes GitHub Wiki
OGC API - Processes - Part 1: Core (version-number)
To comply with Policy Directive 50, the following should be completed.
See an example in the OGC API - Common - Part 1: Core Standard.
# |
Principle |
Discussion |
1 |
Don’t reinvent |
|
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 - Processes - Part 2: Deploy, Replace, Undeploy (version-number)
# |
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 - Processes - Part 3: Workflows (version-number)
# |
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 |
|