Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use of "hypermedia access" #101

Closed
cportele opened this issue Mar 15, 2020 · 2 comments
Closed

Use of "hypermedia access" #101

cportele opened this issue Mar 15, 2020 · 2 comments
Assignees
Labels
Close General General issues from the public review
Projects

Comments

@cportele
Copy link
Member

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.

@akuckartz
Copy link

Yes, (real) REST please! (OpenAPI isn't :-)

@cmheazel cmheazel added the General General issues from the public review label Mar 25, 2020
@cmheazel cmheazel added this to To do in General via automation Mar 25, 2020
@cmheazel cmheazel self-assigned this May 11, 2020
@cmheazel
Copy link
Contributor

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.

@cmheazel cmheazel added the Close label Aug 16, 2020
General automation moved this from To do to Done Aug 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Close General General issues from the public review
Projects
No open projects
General
  
Done
Development

No branches or pull requests

3 participants