Add a property called 'types' as alternative to 'type' in a Link

[ghobona]

The types property implies that there is a content negotiation at the href link.

The format specified in 'type' is the default one. Currently, if you have several formats this results in a more complex encoding that has to repeat a full link for each format.

For example:

"styles": [
    {
      "id": "night",
      "title": "Topographic night style",
      "links": [
        {
          "href": "https://example.com/api/1.0/styles/night",
          "types": ["application/vnd.mapbox.style+json","application/vnd.ogc.sld+xml;version=1.0"],
          "rel": "stylesheet"
        },
        {
          "href": "https://example.com/api/1.0/styles/night/metadata",
          "type": "application/json",
          "rel": "describedby"
        }
      ]
    }

[cportele]

This is in conflict with (the spirit of) RFC 8288 and it would create an OGC-specific approach:

The type attribute MUST NOT appear more than once in a given link-value; occurrences after the first MUST be ignored by parsers.

The "type" link parameter is an optional hint anyhow.

[ghobona]

@cportele Ok, thanks.

[bradh]

Can this be closed?

[jerstlouis]

This issue is already (and should be) in Common: opengeospatial/ogcapi-common#160

So far the approach is to not specify type at all if several types are supported and the server only wishes to provide a single link for all of them. Clients can use the following approach to negotiate a particular format:

• Client can specify all formats it supports in the Accept: header in order of preference
• Dedicated conformance class for a particular format (e.g. Features and Tiles offer this) inform the client of what is possible

Possibly an OPTIONS method could provide another mechanisms to know what types are supported for a specific HTTP method?

[jerstlouis]

Can we close this issue? The two currently described mechanisms (either individual links with a single type, or different links with different types, plyus an Accept: header) is what is consistent with the other OGC API specifications so far (include Tiles). The discussion about OPTIONS as an alternative mechanism can be brought up again and continue in Common.

[joanma747]

This is common issue. We hope we find a solution there. it is #160 in OGC API Common. Decided to close in regular meeting.