Proposal: Remove 'resultType' from core and put in an extension

[cholmes]

(happy to create a PR for the spec changes of this and other issues I'll put in, but I've delayed on getting this feedback out, so figured I'd post now instead of continuing to wait).

Though being able to ask for 'hits' instead of actual results likely seems pretty trivial to implement, it is an additional overhead, and can be more of a pain with a backend like elasticsearch than a standard rdbms. Especially when you get to hundreds of millions of features. At Planet in our data API we have a dedicated 'stats' endpoint that returns the equivalent of 'hits' (see full api spec and search for stats). Ours also can return time bucketed data, which drives nice looking graphs. One could see an advanced 'stats' endpoint being used for crossfilter style interactive filtering.

So a good microservices architecture I believe would have 'hits' be its own endpoint that takes the same 'query' as the 'results' endpoint, so it could be backed by a cluster dedicated and optimized for aggregations. Hits as an extension would allow services to include it if it's easy to implement, but not require it for minimal implementations.

For the SpatioTemporal Asset Catalog spec we started with a draft WFS 3.0 swagger spec, but removed the result type stuff, see the swagger spec

[cportele]

I think you are right. Probably we should see how we support resultType=hits and other related capabilities like #13 and #16 consistently in an extension.

Having a capability to determine the total number of hits is often useful, so we should tackle this soon, if we move it out.

[pvretano]

Yeah, I think I agree with this too. We could probably think about doing something with HEAD to get this kinds of metadata from a server.

[cholmes]

Yes, fully agree that the capability to determine the total number of hits is extremely useful - it was one of my favorite additions.

Just want to be sure it's not required, and that it could easily be implemented in a microservice style architecture. I think there's potential for standardization of even more types of aggregations - like bucketing the stats to drive charts, or even spatial aggregations - return counts by regular geographies, for when a browser can't display all the data. But should be additional end points.

[cportele]

There seems to be consensus on this one. I will create a pull request...

[pvretano]

From teleconference 12-FEB-2018:

• rather than have a resultType extension perhaps this requirement could be satisfied using "microformats" with MIME types and then using the standard content negotiation mechanisms.