Can/should we make use of the new Link Object in OpenAPI 3.0?

[cportele]

https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md#linkObject

[cportele]

I am closing this as no use for this has been identified...

[christophenoel]

As all links (e.g. in the landingPage) are related to other operations, don't you think replacing all current links definitions (currently href, type, etc.) with this format would be relevant? I thought it is a better practice.

For example the mime type is not relevant (in the actual definition) as the openAPI already defines the supported mime types for each operation
.

[cportele]

Even if we would add OpenAPI links, this could not replace the links in the resources like the landing page. For the first approach described below which is more the "hypermedia-driven" we need the links in the resources.

From the spec:

Implementations of OGC API Features are intended to support two different approaches how clients can use the API.

In the first approach, clients are implemented with knowledge about this standard and its resource types. The clients navigate the resources based on this knowledge and based on the responses provided by the API. The API definition may be used to determine details, e.g., on filter parameters, but this may not be necessary depending on the needs of the client. These are clients that are in general able to use multiple APIs as long as they implement OGC API Features.

The other approach targets developers that are not familiar with the OGC API standards, but want to interact with spatial data provided by an API that happens to implement OGC API Features. In this case the developer will study and use the API definition - typically an OpenAPI document - to understand the API and implement the code to interact with the API. This assumes familiarity with the API definition language and the related tooling, but it should not be necessary to study the OGC API standards.