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

support for transactions #107

Open
pvgenuchten opened this issue May 12, 2019 · 6 comments

Comments

@pvgenuchten
Copy link
Contributor

commented May 12, 2019

Ability to delete, insert, update or patch features from the api
OGC-API-Features currently does not offer a specification for transactions yet
However Openapi typically uses DELETE, POST and PUT verbs to update content in an API, so I don't expect much deviation to this in the upcoming ogc api's. It could actually support the discussion there to have an initial implementation available.

Transactions should be disabled by default, and only activated if proper authorisation is in place

Create feature

POST /items/{id} [obj]

Update feature

PUT /items/{id} [obj]

Delete feature

DELETE /items/{id}

Patch feature (partial update)

PATCH /items/{id} [partial obj]
@tomkralidis

This comment has been minimized.

Copy link
Member

commented May 12, 2019

Makes sense. I imagine that functionality will be provider specific/dependent and that our provider base class would throw NotImplementedError by default.

@jachym

This comment has been minimized.

Copy link
Member

commented Oct 8, 2019

Create feature

POST /items/ [obj]

ID should not be forced while feature creation?

ID should be returned

@justb4

This comment has been minimized.

Copy link
Member

commented Oct 8, 2019

My $2ct: The "id thing" requires some thinking-through: it needs to be unique within a Collection on one hand, so IMHO cannot be enforced on the client (think of multiple clients POST/PUTing at the same time), unless maybe with UUIDs. WFS2 had an idgen option, remember? "The idgen attribute control how a WFS generates identifiers from newly created feature instances using the Insert action. The default action is to have the WFS generate a new id for the features. This is also backward compatible with WFS 1.0 where the only action was for the WFS to generate an new id. Don't know if we need this flexibility/complexity, just wanted to mention.
A use case for client-supplied id's are e.g. Cadastral Parcel id's (or INSPIRE-ids brr). Or in SensorWeb: station-ids.

Another example: With SensorThings API Transactions, when POSTing a Thing, the server always generates a unique id (within the Things Collection), but at same time allows a client to set a client-unique field, e.g. a station id within a free-form properties hashmap. So a client can always find back its Things (this was a severe limitation in SOS). Best of both worlds but then again STA has a fixed abstract entity model like an appschema.

@justb4

This comment has been minimized.

Copy link
Member

commented Oct 8, 2019

btw The STAC Pilot Transaction spec (to which OAPIF refers, see above) is IMHO not really clear on this: one POSTs an Item to a Collection and probably if the Item contains an id it is validated for uniqueness and used, otherwise generated (?), but id is mandatory in Item (?). That could be a simple solution without idgen...

@jachym

This comment has been minimized.

Copy link
Member

commented Oct 8, 2019

About the POST /item[s]/[uuid]

It IMHO should return 404, since the endpoint does not exist yet. I have nothing against having required [uu]id in the body of the request

@justb4

This comment has been minimized.

Copy link
Member

commented Oct 8, 2019

POST /collections/{collectionID}/items with a body of Item or even FeatureCollection (have seen latter somewhere, MapFish API?). Item already has an id-field (cannot find back if id is indeed mandatory, seems not in OAPIF. "id is a local identifier of the feature" and ... that strictly only the URI needs to be unique.

Some sources indicate that PUT should be used to add (if Entity not exists) or replace (if exists) a specific Entity (in our case Item):
https://restfulapi.net/rest-put-vs-post/

So

POST /collections/{collectionID}/items [obj]

Adds (new) Item (Feature) to the collection.

and

PUT  /collections/{collectionID}/items/{featureId} [obj]

would add or replace an Item with specific URI (id?).

Update: saw a more recent link to the Stac spec in Gitter from @cholmes, the above aligns with this:
https://github.com/radiantearth/stac-spec/tree/master/api-spec/extensions/transaction

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.