A couple of things to note about the currently proposed rest api.
* Deletes on Workspaces and Stores
It proposes that a DELETE to /workspaces/{wsid} should delete the workspace and any contained data stores. And similarly a DELETE to /workspaces/{wsid}/datastores/{dsid} should delete a datastore and any contained feature types.
I wonder if it would be better to simply not allow DELETE's when the workspaces/datastores are non-empty. And add an explicit parameter to the request to allow DELETE's in the non-empty case. Seems a little nicer in case a user accidentally makes a DELETE against non-empty workspace or datastore that they did not mean to.
* Syles under Workspaces
The proposal puts styles under workspaces in the resource hierarchy. I am not sure if this makes a lot of sense. I think perhaps once we have a publishing/data split, that we could group styles under "maps", but for now styles should go under the root imho.
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
On Mon, 2009-01-12 at 09:14 -0700, Justin Deoliveira wrote:
A couple of things to note about the currently proposed rest api.
* Deletes on Workspaces and Stores
It proposes that a DELETE to /workspaces/{wsid} should delete the
workspace and any contained data stores. And similarly a DELETE to
/workspaces/{wsid}/datastores/{dsid} should delete a datastore and any
contained feature types.
I wonder if it would be better to simply not allow DELETE's when the
workspaces/datastores are non-empty. And add an explicit parameter to
the request to allow DELETE's in the non-empty case. Seems a little
nicer in case a user accidentally makes a DELETE against non-empty
workspace or datastore that they did not mean to.
I could see arguing for the client to take care of this, but I suppose
if our examples recommend using curl then the quickest version of a URL
to type should not be overly destructive. I guess we should add a
parameter &recursive=<boolean> that controls whether or not contained
datastores are removed, along with a &purge=<boolean> that mirrors the
parameter for featuretypes controlling whether the backing data is
removed from disk. &recursive and &purge should also be supported by
coverage- and data-stores; both default to false.
* Syles under Workspaces
The proposal puts styles under workspaces in the resource hierarchy. I
am not sure if this makes a lot of sense. I think perhaps once we have a
publishing/data split, that we could group styles under "maps", but for
now styles should go under the root imho.
Hm, looks like copy and paste went awry. I definitely was thinking
styles would be outside of workspaces. Layergroups should be at the
root level as well, since they are not part of any single namespace.
I'll update the wiki.
-Justin
I could see arguing for the client to take care of this, but I suppose
if our examples recommend using curl then the quickest version of a URL
to type should not be overly destructive. I guess we should add a
parameter &recursive=<boolean> that controls whether or not contained
datastores are removed, along with a &purge=<boolean> that mirrors the
parameter for featuretypes controlling whether the backing data is
removed from disk. &recursive and &purge should also be supported by
coverage- and data-stores; both default to false.
So if I understand correctly, considering a non-empty workspace:
DELETE /workspaces/{wsid} -> 403 and does nothing
DELETE /workspaces/{wsid}?recursive=true -> 200 and recursively deletes all datastores and feature types but keeps the backing files on disk around
DELETE /workspaces/{wsid}?recursive=true&purge=true -> 200 and deletes recursively and removes files from disk
I could go for this... however I wonder how it will apply when we get a hibernate backed configuration. I guess we will have to set up some temporary table for backup storage or something... or perhaps this is something that hibernate can do? Not sure.
* Syles under Workspaces
The proposal puts styles under workspaces in the resource hierarchy. I am not sure if this makes a lot of sense. I think perhaps once we have a publishing/data split, that we could group styles under "maps", but for now styles should go under the root imho.
Hm, looks like copy and paste went awry. I definitely was thinking
styles would be outside of workspaces. Layergroups should be at the
root level as well, since they are not part of any single namespace.
I'll update the wiki.
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
DELETE /workspaces/{wsid} -> 403 and does nothing
DELETE /workspaces/{wsid}?recursive=true -> 200 and recursively deletes all datastores and feature types but keeps the backing files on disk around
DELETE /workspaces/{wsid}?recursive=true&purge=true -> 200 and deletes recursively and removes files from disk
It seems i mis understood the semantics of purge, it refers to deleting the underlying dataset, not just the configuration. In my opinion I don't see this as being something we want to handle. Firstly b/c it seems like too easy a way shoot oneself in the foot. Secondly it is often the case where a user who has privileges to admin GeoServer does not have privileges to wipe out an underlying database....
Anyways, i am curious to here other peoples thoughts on this, and if they think it is a worth while feature.
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.