WFS3 Probes: enforce JSON responses

[justb4]

Intro

See this discussion on Gitter

Problem

There is no default format for OGC API Features (formerly WFS3) responses. Current WFS3 Probes assume JSON responses.

Solution

Enforce JSON responses, e.g. by adding ?f=json to request URLs.

[tomkralidis]

Note that f is not a formal parameter, so some options to think about down the line:

• have a note that the user must enter a URL which returns an OAPIF landing page in JSON
• take some educated guesses (f seems to be the first out the gate)

[justb4]

Hmm, also tried to follow: opengeospatial/ogcapi-features#179

IMHO no default nor format parameter makes the standard almost unusable, at least a source for much confusion. At least with WFS1 and 2 we could count on default (XML) and outputType.
Why not just standardize that with no "Accept" headers, nor content negotiation, JSON is the default for the top endpoint? I think most modern APIs follow that convention. But this discussion should be done elsewhere.

Adding a user-note is not workable, given that even now many (don't read the current note) and paste in full GetCapabilities URLs (while the note explicitly says not to do that). Maybe educated guesses is for now the best option. I've even seen the .<format> convention mixed with f= as in:

• curl http://beta.fmi.fi/data/3/wfs/sofp (JSON) (HTML in browser)
• curl http://beta.fmi.fi/data/3/wfs/sofp?f=html (HTML)
• http://beta.fmi.fi/data/3/wfs/sofp?f=json (JSON)
• http://beta.fmi.fi/data/3/wfs/sofp.json (fails)
• http://beta.fmi.fi/data/3/wfs/sofp/api.json (JSON)
• http://beta.fmi.fi/data/3/wfs/sofp/api?f=json (fails)

In hinsight seems to make the most sense: default JSON in top endpoint and specify formats for sub-paths in links therein. Is the name rel standardized here?

Also default sometimes differs within endpoint, e.g.:

• curl https://services.interactive-instruments.de/t15/daraa (JSON)
• curl https://services.interactive-instruments.de/t15/daraa/api (YAML)

[justb4]

Ok got further Following up, I missed many of the discussions: Suppose a client (GHC Probe), maybe through educated guesses like f=json, appending .json etc has a JSON (or other) representation of the top-endpoint/Landing Page. How can it crawl further? The <links> section points to services but is the rel attribute in each link standardized? e.g. rel=service denotes the OpenAPI description and rel=data the Collections? See e.g. https://demo.pygeoapi.io/master?f=json (rel=service) and https://services.interactive-instruments.de/t15/daraa?f=json (rel=service-desc).

(Yes, I see rel is standardized now: https://github.com/opengeospatial/ogcapi-features/blob/master/core/standard/clause_7_core.adoc so we should adapt pygeoapi and OWSLib as well)

[justb4]

Forgot about this over year-old issue. Will use Content Negotiation based on recent discussion:

You have to use the Accept header, this is the only requirement in the standard, consistent with the HTTP standard. http://docs.opengeospatial.org/is/17-069r3/17-069r3.html#encodings