pygeoapi
pygeoapi copied to clipboard
geopython
support for transactions
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]
Makes sense. I imagine that functionality will be provider specific/dependent and that our provider base class would throw NotImplementedError by default.
Create feature
POST /items/ [obj]
ID should not be forced while feature creation?
ID should be returned
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.
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...
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
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
@justb4 I would also consider PATCH to change only a feature property:
PATCH /collections/{collectionID}/items/{featureId} [obj]
would change the field value of an item, it could also be the geometry
@francbartoli thanks, yes PATCH for partial updates (except for id itself IMHO) should be considered.
Note: transactions draft now at http://docs.opengeospatial.org/DRAFTS/20-002.html
Thanks @tomkralidis, very good reference to follow for the implementation
For now, we continue to monitor the OGC draft for developments, contributions against are welcome.