This page last changed on Jan 14, 2011 by jdeolive.


Some general improvements to the RESTConfig api.

Proposed By

Justin Deoliveira

Assigned to Release





Some improvements to the REST configuration api in order to make it a bit more friendly.


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


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.


Andrea Aime: +1
Alessio Fabiani:
Gabriel Roldán: +1
Justin Deoliveira: +1
Jody Garnett: +1
Mark Leslie:
Simone Giannecchini: +0
Chris Holmes: +1


JIRA Tasks

Email Discussion
[Wiki Page|]

Document generated by Confluence on May 14, 2014 23:00