Support for POST?

[cportele]

Do we need support for POST at /collections/{collectionId}/items?

This could be useful/necessary for filter expressions with large geometries (this could use application/x-www-form-urlencoded with cql-text) or for filter expressions with cql-json (with media type application/json and an object with a property for each parameter).

[cholmes]

+1 on this in general. Though I just remembered that POST on /items I believe is taken by the transaction (which makes sense).

In STAC we use it on the /search endpoint, where the semantics make more sense - you post to 'create' a new search (could actually return a search object, but we thought it was reasonable to make it a 'quick search' where you post and receive the response all in one). I saw that /search was mentioned in CQL, has it been specified anywhere else? That'd be one of the remaining things that enables STAC API to just be a collection of best practices of Features API plus the STAC content type.

[cportele]

/search (multi-collection data retrieval) is not yet specified. It is foreseen for another part (I hope in the next batch of tasks that the SWG can add to the charter).

Yes, POST to items is specified in transactions, but I don't think that this has to preclude the use POST on items for other purposes. The different process triggered by the request depends on the content provided. If it is GeoJSON, it is an insert. If it is a JSON query object (it probably would be good to register a specific media type for this), it returns features matching the filter. AFAICT there is not issue with HTTP here.

[cholmes]

Ah, interesting. Didn't realize POST could work that day - you learn something new every day :)

I suppose we'll charge ahead in STAC, but would be great to have you review it so we have a chance of aligning to what's to come from Features API. We'll probably just stick with POST-ing to /search, as you can specify a single collection there, but ideally the request would be pretty much the same.

[pvretano]

@cholmes the behaviour is controlled by the content type. POST with application/geo+json you have an insert. POST with application/x-www-form-url you have a query. POST is flexible that way. However, I would prefer the STAC approach by using something like a /collections/{collectionId}/search endpoint just to separate concerns. POST a filter expression (CQL, or something else) to /collections/{collectionId}/search and you execute a query using the specified filter expression; easy, clean. Also, a top-level /search?collections=A,B lets you do cross-collections queries and even (dare I say it) spatial joins! ;)

[cholmes]

Cool. For now in STAC we just have top-level /search And will probably stick with that as it makes describing it simpler: implement Features API, and add the /search endpoint. But happy to have that approach at the collection level too, just will wait for you all to specify it.

The other aspect to potentially think about is 'saved search' - post a persistent search query that you can revisit, and stays up to date. In Planet's API that's what our /search/ endpoint does, and then we have a 'quick-search' which behaves like we're saying - POST and get results. See https://developers.planet.com/docs/data/quick-saved-search/

[pvretano]

@cholmes well, I did not want to bring that up (too much info in one shot) but the issues of stored queries that has been on my mind for a very long time (see https://portal.ogc.org/files/?artifact_id=44852&version=1). So, yes, stored queries are on our radar. The plan, as @cportele mentioned, is to write an "complex query" extension (bad name?) that incorporates all these search endpoint ideas. First, however, we need to finish CQL and Simple Transactions (which of course implies there will be a complex Transactions too). ;)

[cholmes]

Cool, great to hear that's on the radar too. The other more advanced query thing I'd love to see is aggregation. Planet has done bits of that in our custom data api's, and wants to do more. And Astraea implemented some with STAC, and made a proposal - https://github.com/radiantearth/stac-api-spec/pull/36/files And that really belongs more at the Features API level.

I do think 'complex query' is a bad name. I'd encourage moving away from simple vs complex nomenclature, and to not bundle all advanced things in a single extension. Have each idea as its own, very small extension. Complex doesn't communicate anything except that it's 'not simple'. Simple at least communicates 'start here'. Though in transactions, for example, I'd just call it 'CRUD transactions' instead of 'simple transactions'. I forget what exactly is planned for 'complex' ones, but I'd say if there's two or three ideas that can stand alone then don't bundle them in 'complex'. Similar with search - a cross-collection search as one thing, joins as another (depends on cross-collection search), POST-ing a search is another. I think it's fine if they're a coherent work item to think through and produce them all at once, but from a user perspective I think it's better not to 'bundle' them. Just my 2 cents...

And yes, agree on finishing CQL and Transactions first :)

[cportele]

However, I would prefer the STAC approach by using something like a /collections/{collectionId}/search endpoint just to separate concerns.

Makes sense, but then this would go into the extension that will specify the search resources and not Filtering/CQL?

I'd encourage moving away from simple vs complex nomenclature, and to not bundle all advanced things in a single extension.

+1 on this, in particular with respect to not use "complex" and for not bundling more advanced capabilities in a single extension. We should identify the capability that a spec adds and name the extension accordingly. The use of "simple" can be ok, I think, but I also see that being more explicit like "CRUD" or "CRUD operations" may be better. We could then simply use "Transactions" for the next extension.

In the same sense I would call the extension that specifies the key aspects of the search resource (under root and under collections) "Queries". Whether that would already include stored queries or whatever we will call them is a topic for discussion.

I think I will open a new issue for discussion of priorities for what follows after the current tasks/extensions in the SWG charter are complete...

[pvretano]

@cportele correct, a search extension would not be part of Filter/CQL. It would be a separate extension. @cholmes @cportele, yes the simple/complex nomenclature is not the best.

[cportele]

Meeting 2020-11-09: It will be added in the future Query / Search extension and not be included in Part 3.

[cportele]

Related to this, there is also a discussion about a SEARCH method: HTTP SEARCH Method

[cportele]

That IETF draft has evolved and the proposed HTTP method is now QUERY:

https://www.ietf.org/archive/id/draft-ietf-httpbis-safe-method-w-body-02.html