opengeospatial / OGC-Web-API-Guidelines

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Principle #3b – Keep the Base URL Simple

cmheazel opened this issue · comments

• Never release an API without versioning
• Use a version string as the most left of your path
– /v1 (don’t you dot notation)
• Add the kind of resource to the path
– /v1/{features, maps, tiles, coverages, processes}
• Use nouns not verbs to build the path
– /v1/features/highway or /v1/maps/topo25 etc.
• Use two base URLs per resource kind
• Use HTTP methods as verbs
– GET /v1/features/highway or /v1/features/highway/A8

cmheazel included this in issue #19 that has been closed.
This principle calls for uniformity on how OGC API URLs are structured.

  • Starting with a URL template, what are the rules for:Protocol (http, https, file, etc.)
  • Authority (DNS name)
  • Path (identifies the resource type)
  • Query (selects the resources)

Some of the Principles deal with parts of the issue, but none address the elephant as a whole: #3 #5 #7 #8 #14 #15

Never release an API without versioning information
Use a version string as the most left most element of your path
...

This is out of scope and should be removed. OGC standards should not define APIs, but building blocks for APIs.

now addressed in master