I'm coming from a Rails background, and am not very familiar with geoserver internals, so might be off-base, but I was expecting something like the following.
Just going from the geoserver user interface it seems that there are six types of resources that might be exposed via the rest api.
Namespaces
CoverageStores
DataStores
Styles
FeatureTypes
Coverages
And assuming that CoverageStores contain Coverages, and DataStores contain FeatureTypes (is this a true assumption?), then we have a set of "resources" like this:
/namespaces
/coverage_stores/<store_id>/coverages/<coverageid>
/data_stores/<store_id>/features/<feature_id>
/styles
So to upload a new geotiff, to a directory named img_sample, with a layer name of satellite_image, you would do this:
PUT /rest/coverage_stores/img_sample/coverages/satellite_image.tiff
You could also get the geotiff back by performing a GET to that URL.
If you wanted to publish a geotiff via a url, you would set the Content-Type to text/url or something like that, and the body of the PUT would be a URL pointing to the geotiff, but I would send the HTTP request to the same URI used above.
One question that remains in my mind is if the actual data of the coverage (TIFF, grib, etc) and its configuration information (srid, bounding box) are treated as separate resources and put at different URIs, or if they can be accessed and updated as different representations of the same resource. I think I lean towards the latter interpretation: then all data relating to a coverage would exist at a single URI. Accessing different 'representations' of that coverage could be done with the Content-Type: and Accepts: headers, or the file extension, or even with url parameters.
-Pete
On Jan 2, 2009, at 2:55 PM, David Winslow wrote:
Whoops, didn't mean to point a finger at Simone. The 'virtual folder'
concept is something I implemented shortly before I stopped working on
the RESTConfig module; it was suggested by some folks here at OpenGeo as
a possible direction to move in for the purpose of simplifying the
complexity of the REST API. It hasn't really been pushed very hard in
'real world' use, and in general I'm quite open to redesign suggestions
for the API.
I would agree that PUTting a URL to one path and having it create a
resource at a different path is not very restful, especially since I
don't think GeoServer keeps track of the URL that was originally sent,
so you have a successful PUT to a resource that will 404 immediately
afterward. However, I'm not really sure what the proper HTTP phrasing
of that request (fetch a resource from URL x and publish it as URL y)
would look like. As a first guess I would say:
POST /folders/f/layers?datasource=<url-encoded url to data
source>&name=<layer name to be fudged as needed by geoserver>
Where the query parameters might be form-encoded instead of sent in the
address field.
--
David Winslow
Justin Deoliveira wrote:
Cool, thanks for clarifying David.
Looking at the folder structure I don't quite understand it much either.
It seems more or less to be just a reflection of whats on disk when
working with shapefile and geotiff formats. Which is sort of a
divergence of what we mapped out before. Perhaps Simone can enlighten
further.
David Winslow wrote:
Well, the folders/{folder}/layers/{layer}/url.{format} endpoint has been
added since the last time I took a close look at the RESTConfig module,
so I'm not 100% familiar with its usage. However, for looking up
coverage configurations in a GET request, the {folder} parameter is
interpreted as a "virtual folder." This is basically the name of the
directory for filesystem-backed data/coveragestores and the name of the
datastore for others. For configuration of existing data/coveragestores
you should use this convention. In this case specifically, you should
DELETE /rest/folders/data/layers/AutoPublish .
I believe that the 'data' folder arose from the fact that the url
endpoint actually fetches the specified file and saves it in the data
directory, regardless of whether it's a local file or not. Simone
(cc'ed) would know more.
Hope this helps,
David Winslow
On Fri, 2009-01-02 at 12:57 -0600, Pete Schwamb wrote:
I spent some time figuring out how to upload geotiff coverages to
geoserver using the RESTful config module, and was able to do so
successfully, but I had some questions about the the organization of
the resulting resources under /rest.
I uploaded the tif using the url action like this:
url -T sat_url.txt -v -XPUT --basic --user
admin:geoserver http://localhost:8080/geoserver/rest/folders/AutoPublish/layers/SatIR/url.geotiff
The sat_url.txt file had the following contents:
file:/Users/pete/dev/geoserver-1.7.1/data_dir/coverages/SatData/Satellite_Image.tif
Since I published to /rest/folders/AutoPublish/layers/SatIR/, I would
expect to see a folder named AutoPublish, and a layer named SatIR, but
instead I see the new resource
at /rest/folders/data/layers/AutoPublish.
Where did this folder called 'data' come from? Maybe I just don't
understand the layout. I'd like to be able to programatically delete
the layers, but I don't know what resource URI to delete. As far as I
understand it, being RESTful means that I should be able to use the
same URI to perform different operations on the same resource.
-Pete
------------------------------------------------------------------------------
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
------------------------------------------------------------------------------
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
------------------------------------------------------------------------------
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users