STAC API description of POST implementation #489
Conversation
api-spec/api-spec.md
Outdated
| | bbox | [number] | WFS3, STAC | Requested bounding box [west, south, east, north] | | ||
| | time | string | WFS3, STAC | Single date, date+time, or a range ('/' seperator), formatted to [RFC 3339, section 5.6](https://tools.ietf.org/html/rfc3339#section-5.6) | | ||
| | intersects | GeoJSON Feature | STAC | Searches items by performing intersection between their geometry and provided GeoJSON Feature | | ||
| | page | number | STAC | The page number of results. Defaults to 1 | |
There was a problem hiding this comment.
the change from page -> next will be picked up by a different PR.
|
The Filter Parameters table shows limit and page typed as |
Yes, sure! Edit: Applied the changes, also in the openAPI files. |
m-mohr
force-pushed
the
api-stac-search-post
branch
from
ec7a537 to
ab83ef2
Compare
|
What's supposed to be the difference between the api-spec/STAC.yaml and api-spec/openapi/STAC.yaml? |
STAC.yaml is generatred from openapi/STAC.yaml (and others like WFS). I.e. openapi/STAC.yaml is a fragment, which only includes the core STAC API without extensions and external input such as WFS. |
Ah, understand that in the documentation now. |
|
This PR is ready for merge pending approval. |
api-spec/api-spec.md
Outdated
|
|
||
| ### WFS3 Endpoints | ||
| Since STAC adds additional filter parameters that may have much larger values, like `intersects`, it is **recommended** to also support `POST` for both the WFS3 and STAC endpoints that | ||
| accept filter parameters (e.g., `/collections/{collection_id}/items` and `/stac/search`). |
There was a problem hiding this comment.
I think here we do not want to recommend supporting POST for the collections endpoints as this conflicts with the transactions extension: https://github.com/radiantearth/stac-spec/tree/master/api-spec/extensions/transaction
I believe we want to recommend that for more complex searches that require POST to exclusively use the /stac/search endpoint.
There was a problem hiding this comment.
I agree with that as to not conflict with the Transactions Ext as it is currently defined.
However, I think we should reconsider whether or not Transactions should extend the behavior of the paths defined in WFS 3. For example, what if an existing WFS 3 implementation has already implemented the GET and POST form-data operations on /collections/{collectionID}/items? I feel that if we want to provide extensions/behaviors on top of the ones defined by WFS 3 that we should duplicate the endpoints, such that, for example, we have /collections/{collectionID}/items that implements only the WFS 3 semantics, and /stac/collections/{collectionID}/items that implements our own semantics (e.g., the transactions POST behavior)
There was a problem hiding this comment.
So originally, before it was an actual extension, I used PUT, PATCH, and DELETE to handle creating, updating, and deleting items against the dynamic api endpoint. I think it was during the second sprint it was decided that transactions should be executed via the collections endpoint. I'm not 100% certain why. @m-mohr is there a WFS-T3 spec that defines transactions against the collections endpoint? We also have our own catalog endpoints. Would that make more sense?
There was a problem hiding this comment.
I don't think there's as much conflict as I originally thought. I think we just needed to be explicit about the use of the application/json . See the changes in e7dbfaa
There was a problem hiding this comment.
@joshfix Not yet, as far as I know, but there will probably be a WFS-T extension in the future that we could adopt.
Fine with the changes by @philvarner. Approved (again).
No description provided.