Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
STAC API description of POST implementation #489
STAC API description of POST implementation #489
Changes from 1 commit
0fc4870
c318949
00aef64
02d0b38
07d47a9
ab83ef2
94959fd
e7dbfaa
de604e5
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 e7dbfaaThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the change from page -> next will be picked up by a different PR.