You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue has been created as part of the public review and is based on document 19-072. See in particular sections 8.1.3 and 9.1.
I would not call the first approach "hypermedia access", because I don't think that it is fully adequate plus we are getting into "REST" discussion territory again. The main goal of this approach is to simplify the development of clients that work out-of-the-box with multiple APIs conforming to OGC API standards. I don't think the APIs are fully self-descriptive and clients won't be able to use all those APIs without some knowledge about either the particular API or the OGC API standard. Here is how we characterized it in Features:
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.
The text was updated successfully, but these errors were encountered:
Section 7.3 has been renamed "Using APIs". The content has been replaced with the content identified by @cportele .
The previous contents of Section 7.3 have been moved to section 6.3 "Link Relations".
Added to Section 6.3 a link to the Users Guide where there is a discussion on link relations.
This issue has been created as part of the public review and is based on document 19-072. See in particular sections 8.1.3 and 9.1.
I would not call the first approach "hypermedia access", because I don't think that it is fully adequate plus we are getting into "REST" discussion territory again. The main goal of this approach is to simplify the development of clients that work out-of-the-box with multiple APIs conforming to OGC API standards. I don't think the APIs are fully self-descriptive and clients won't be able to use all those APIs without some knowledge about either the particular API or the OGC API standard. Here is how we characterized it in Features:
The text was updated successfully, but these errors were encountered: