GSIP 58 - RESTConfig API Improvements
Overview
Some general improvements to the RESTConfig api.
Proposed By
Assigned to Release
TBD
State
Completed
Motivation
Some improvements to the REST configuration api in order to make it a bit more friendly.
Proposal
Recursive DELETE
There are two major bits of functionality within this proposal. The first is the ability to recursively delete resources. For instance as the api stands now in order to full delete a workspace the client must first delete all the stores within that workspace, which involves deleting all the resources in those stores, which involves deleting any layers referencing those resources.
Quite a burden on the client. The idea is to add a flag called recurse, that when set to true will recursively delete resources. For example:
DELETE /rest/workspaces/topp?recurse=true
Store File Upload
One of the most widely used features of the REST api is the ability to upload a zipped shapefile and have it automatically configure a store / feature type, etc... However somewhat limiting in that there are no options to control how the store is created. Essentially always a single shapefile datastore is created.
The idea is to allow the user to upload into an existing store. For example perhaps the user does not want to serve the shapefile as a shapefile datstore, but convert into postgis and have it served from there. Which this change they can use the same api they used before but instead specify the existing postgis store. And the rest api will do the conversion as required.
With the current api when the user uploads into a store that already exists the previous data is overwritten. This proposal also introduces the ability to control this with a new parameter called update which can have the values "append", or "overwrite". The default is "overwrite" to maintain api backwards compatibility. Examples:
PUT /rest/workspaces/foo/datastores/bar/file.shp?update=append
Feedback
This section should contain feedback provided by PSC members who may have a problem with the proposal.
Backwards Compatibility
API wise there should be no backwards incompatibilities. The semantics of uploading a file to an existing store have changed slightly but only in cases in which the store is not the type of the file being uploaded, which is not supported in the existing apis.
Voting
Andrea Aime: +1
Alessio Fabiani:
Gabriel Roldán: +1
Justin Deoliveira: +1
Jody Garnett: +1
Mark Leslie:
[~roba]:
Simone Giannecchini: +0
Chris Holmes: +1
Links
JIRA Tasks
http://jira.codehaus.org/browse/GEOS-4183 http://jira.codehaus.org/browse/GEOS-4292
Email Discussion
[Wiki Page|]