[Geoserver-devel] RESTConfig

Alessio_Fabiani · May 15, 2008, 9:52am

Hi guys,

I made few improvements to the GeoServer RESTConfig and sldService stuff which I would like to briefly discuss here, and in case of interest I can commit it:

DataStoreFileResource: this class originally was intended to let GeoServer get a shapefile and create a new datastore. I corrected some errors and changed a bit the behavior. Originally this resource was checking just for the arrival of a single .shp file, which is not sufficient for my needs; so I changed it in order to let it accept a ZIP file containing the whole Shapefile stuff, decompress it into GeoServer data dir, create the new datastore and contextually create the FeatureType also.
FeatureTypeResource: this class allows a user to insert/update a FeatureType. Originally the resource constrained the user to send the whole feature type properties everytime. I changed a bit in order to let a user to update also just some of the properties of the FeatureType if the latter is already present in the catalog.
StyleResource: this resource was incomplete, in particoular it didn’t save the style on the catalog and also didn’t check for the style existence in the case of a replacement. I changed it to perform those tasks.
SimpleClient: I put this simple utility class in the test package in order to allow users to perform simple GET/POST/PUT/DELETE requests to the REST interfaces. It is not fully complete though.
on sldService I added few Resources to let users to easily generate color classifications and optionally color Ramps, without the need to create and save a new SLD. Maybe they are redoundant, but very usefull to me. On a POST request, the user can specify the datasotre, the property, the type of color quantization to apply and the number of classes. The user can also send as optional parameters of the form the type of color ramp to generate and in case of custom color ramp also the start, end and mid colors. The result is a JSON string representing the quantization rules. Each rule consists basically of a title, a filter and if the color ramp was specificed a symbolizer describing the fill to apply.
I added to the sldService a UserStyleResource which allows a user to modify the default SLD of a wms layer, independetly if it is generated from a featuretype or a coverage. Not yet fully complete though.

Cheers,
Alessio.

–

Eng. Alessio Fabiani
Vice-President /CTO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 349 8227000

http://www.geo-solutions.it

Andrea_Aime3 · May 16, 2008, 8:29am

Alessio Fabiani ha scritto:

Hi guys,

I made few improvements to the GeoServer RESTConfig and sldService stuff which I would like to briefly discuss here, and in case of interest I can commit it:

1. DataStoreFileResource: this class originally was intended to let GeoServer get a shapefile and create a new datastore. I corrected some errors and changed a bit the behavior. Originally this resource was checking just for the arrival of a single .shp file, which is not sufficient for my needs; so I changed it in order to let it accept a ZIP file containing the whole Shapefile stuff, decompress it into GeoServer data dir, create the new datastore and contextually create the FeatureType also.

This seems sensible to me. David?

2. FeatureTypeResource: this class allows a user to insert/update a FeatureType. Originally the resource constrained the user to send the whole feature type properties everytime. I changed a bit in order to let a user to update also just some of the properties of the FeatureType if the latter is already present in the catalog.

Hum, how do you do that? Are you exposing the properties as sub-resources? In REST there is no partial update of a resource afaik,
usually that is obtained by exposing explicitly what you want to make
modifiable singularly.

3. StyleResource: this resource was incomplete, in particoular it didn't save the style on the catalog and also didn't check for the style existence in the case of a replacement. I changed it to perform those tasks.

Sounds sensible again.

4. SimpleClient: I put this simple utility class in the test package in order to allow users to perform simple GET/POST/PUT/DELETE requests to the REST interfaces. It is not fully complete though.

Is it any better than using curl on the command line? (did not look,
just wondering).

5. on sldService I added few Resources to let users to easily generate color classifications and optionally color Ramps, without the need to create and save a new SLD. Maybe they are redoundant, but very usefull to me. On a POST request, the user can specify the datasotre, the property, the type of color quantization to apply and the number of classes.

POST == creation of new resource. If your code is just returning
a style without storing it on the server, the request should be a GET.
Moreover, why specify a datastore? Wouldn't it be better to have
a GET request on the FeatureType node that looks like

.../topp:states?request=classify&attribute=myAtt&method=quantile&intervals=5&ramp=red

The user can also send as optional parameters of the form the type of color ramp to generate and in case of custom color ramp also the start, end and mid colors. The result is a JSON string representing the quantization rules. Each rule consists basically of a title, a filter and if the color ramp was specificed a symbolizer describing the fill to apply.

6. I added to the sldService a UserStyleResource which allows a user to modify the default SLD of a wms layer, independetly if it is generated from a featuretype or a coverage. Not yet fully complete though.

I thought that was already covered by RESTConfig?
Cheers
Andrea

Andrea_Aime3 · May 16, 2008, 9:08am

Andrea Aime ha scritto:

POST == creation of new resource. If your code is just returning
a style without storing it on the server, the request should be a GET.
Moreover, why specify a datastore? Wouldn't it be better to have
a GET request on the FeatureType node that looks like

.../topp:states?request=classify&attribute=myAtt&method=quantile&intervals=5&ramp=red

A bit more on algorithic resources here:
http://blog.cleverelephant.ca/2007/08/rest-without-resources.html

Cheers
Andrea

Luca_Morandini2 · May 16, 2008, 10:11am

Andrea Aime wrote:

Is it any better than using curl on the command line? (did not look,
just wondering).

FYI, I have found Poster (a FireFox add-on) to be rather handy for testing web-services interactively.

https://addons.mozilla.org/en-US/firefox/addon/2691

--------------------
Luca Morandini
www.lucamorandini.it
--------------------

David_Winslow · May 16, 2008, 1:08pm

Andrea Aime wrote:

Alessio Fabiani ha scritto:

Hi guys,

I made few improvements to the GeoServer RESTConfig and sldService stuff which I would like to briefly discuss here, and in case of interest I can commit it:

1. DataStoreFileResource: this class originally was intended to let GeoServer get a shapefile and create a new datastore. I corrected some errors and changed a bit the behavior. Originally this resource was checking just for the arrival of a single .shp file, which is not sufficient for my needs; so I changed it in order to let it accept a ZIP file containing the whole Shapefile stuff, decompress it into GeoServer data dir, create the new datastore and contextually create the FeatureType also.

This seems sensible to me. David?

This sounds a bit off to me, the DataStoreFileResource that was already there should have been accepting a ZIP file with the shapefile and its companions. I will look over the code in SVN and figure out what the confusion is here. (Hunch: I put the ZIP stuff in trunk after the 1.6.x branch of RESTconfig was created.) Anyway, I am all for having the ZIPped fileset instead of just the shapefile.

2. FeatureTypeResource: this class allows a user to insert/update a FeatureType. Originally the resource constrained the user to send the whole feature type properties everytime. I changed a bit in order to let a user to update also just some of the properties of the FeatureType if the latter is already present in the catalog.

Hum, how do you do that? Are you exposing the properties as sub-resources? In REST there is no partial update of a resource afaik,
usually that is obtained by exposing explicitly what you want to make
modifiable singularly.

aaime++

3. StyleResource: this resource was incomplete, in particoular it didn't save the style on the catalog and also didn't check for the style existence in the case of a replacement. I changed it to perform those tasks.

Sounds sensible again.

Hm, sounds like another mismatch between trunk and 1.6.x. Again, all for the improvements if they're not already there.

4. SimpleClient: I put this simple utility class in the test package in order to allow users to perform simple GET/POST/PUT/DELETE requests to the REST interfaces. It is not fully complete though.

Is it any better than using curl on the command line? (did not look,
just wondering).

Other clients I've used for quick REST requests include http://restclient.org/ and the firefox extension RESTTest (http://addons.mozilla.org/en-US/firefox/addon/5946)

5. on sldService I added few Resources to let users to easily generate color classifications and optionally color Ramps, without the need to create and save a new SLD. Maybe they are redoundant, but very usefull to me. On a POST request, the user can specify the datasotre, the property, the type of color quantization to apply and the number of classes.

POST == creation of new resource. If your code is just returning
a style without storing it on the server, the request should be a GET.
Moreover, why specify a datastore? Wouldn't it be better to have
a GET request on the FeatureType node that looks like

.../topp:states?request=classify&attribute=myAtt&method=quantile&intervals=5&ramp=red

The user can also send as optional parameters of the form the type of color ramp to generate and in case of custom color ramp also the start, end and mid colors. The result is a JSON string representing the quantization rules. Each rule consists basically of a title, a filter and if the color ramp was specificed a symbolizer describing the fill to apply.

6. I added to the sldService a UserStyleResource which allows a user to modify the default SLD of a wms layer, independetly if it is generated from a featuretype or a coverage. Not yet fully complete though.

I thought that was already covered by RESTConfig?

Yes, me too. What does this accomplish that isn't met by the existing code?

Cheers
Andrea

!DSPAM:4040,482d45ed41092085621377!

-david

Alessio_Fabiani · May 27, 2008, 9:07am

Hi all,

few updates …

DataStoreFileResource: we have aligned the code with the one on trunk. David was right the resource on trunk was alredy handling ZIP archives. We just checked the all works fine and added better control on the DefaultStyle attribute assignement. In the old version that was by default setted to “polygon”, now we check the type of Geometry and assign the right style consequently.
Removed SimpleClient test class since it is not so useful
Removed the resources for the generation of SLD classifiers against PUT requests on sldService module, and added just one which on a GET request with some parameter as indicated by Andrea, generates classified SLD, and eventually color-ramps, on the fly without saving it on the catalog.
The UserStyleResource is different from the actual implementation since it does not need the datastore and the featureTypes like the one in RESTConfig, but the WMS Layer ID, which could be derived both from a FeatureType or a Coverage.

That’s all for now, we are working on the other points also.

Regards,
Alessio.

On Fri, May 16, 2008 at 3:08 PM, David Winslow <dwinslow@anonymised.com> wrote:

Andrea Aime wrote:

Alessio Fabiani ha scritto:

Hi guys,

I made few improvements to the GeoServer RESTConfig and sldService stuff which I would like to briefly discuss here, and in case of interest I can commit it:

DataStoreFileResource: this class originally was intended to let GeoServer get a shapefile and create a new datastore. I corrected some errors and changed a bit the behavior. Originally this resource was checking just for the arrival of a single .shp file, which is not sufficient for my needs; so I changed it in order to let it accept a ZIP file containing the whole Shapefile stuff, decompress it into GeoServer data dir, create the new datastore and contextually create the FeatureType also.

This seems sensible to me. David?

This sounds a bit off to me, the DataStoreFileResource that was already there should have been accepting a ZIP file with the shapefile and its companions. I will look over the code in SVN and figure out what the confusion is here. (Hunch: I put the ZIP stuff in trunk after the 1.6.x branch of RESTconfig was created.) Anyway, I am all for having the ZIPped fileset instead of just the shapefile.

FeatureTypeResource: this class allows a user to insert/update a FeatureType. Originally the resource constrained the user to send the whole feature type properties everytime. I changed a bit in order to let a user to update also just some of the properties of the FeatureType if the latter is already present in the catalog.

Hum, how do you do that? Are you exposing the properties as sub-resources? In REST there is no partial update of a resource afaik,
usually that is obtained by exposing explicitly what you want to make
modifiable singularly.

aaime++

StyleResource: this resource was incomplete, in particoular it didn’t save the style on the catalog and also didn’t check for the style existence in the case of a replacement. I changed it to perform those tasks.

Sounds sensible again.

Hm, sounds like another mismatch between trunk and 1.6.x. Again, all for the improvements if they’re not already there.

SimpleClient: I put this simple utility class in the test package in order to allow users to perform simple GET/POST/PUT/DELETE requests to the REST interfaces. It is not fully complete though.

Is it any better than using curl on the command line? (did not look,
just wondering).

Other clients I’ve used for quick REST requests include http://restclient.org/ and the firefox extension RESTTest (http://addons.mozilla.org/en-US/firefox/addon/5946)

on sldService I added few Resources to let users to easily generate color classifications and optionally color Ramps, without the need to create and save a new SLD. Maybe they are redoundant, but very usefull to me. On a POST request, the user can specify the datasotre, the property, the type of color quantization to apply and the number of classes.

POST == creation of new resource. If your code is just returning
a style without storing it on the server, the request should be a GET.
Moreover, why specify a datastore? Wouldn’t it be better to have
a GET request on the FeatureType node that looks like

…/topp:states?request=classify&attribute=myAtt&method=quantile&intervals=5&ramp=red

The user can also send as optional parameters of the form the type of color ramp to generate and in case of custom color ramp also the start, end and mid colors. The result is a JSON string representing the quantization rules. Each rule consists basically of a title, a filter and if the color ramp was specificed a symbolizer describing the fill to apply.

I added to the sldService a UserStyleResource which allows a user to modify the default SLD of a wms layer, independetly if it is generated from a featuretype or a coverage. Not yet fully complete though.

I thought that was already covered by RESTConfig?

Yes, me too. What does this accomplish that isn’t met by the existing code?

Cheers
Andrea

!DSPAM:4040,482d45ed41092085621377!

-david

–

Eng. Alessio Fabiani
Vice-President /CTO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 349 8227000

http://www.geo-solutions.it