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

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

Closed
cholmes opened this issue Dec 13, 2017 · 5 comments
Closed

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

cholmes opened this issue Dec 13, 2017 · 5 comments

Comments

@cholmes
Copy link
Member

cholmes commented Dec 13, 2017

(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
Copy link
Member

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
Copy link
Contributor

pvretano commented Dec 14, 2017

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
Copy link
Member Author

cholmes commented Dec 15, 2017

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 cportele added this to the Part 1, First Draft milestone Jan 29, 2018
@cportele
Copy link
Member

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

@pvretano
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants