On Wed, Jan 25, 2012 at 6:39 PM, David Winslow <dwins...@opengeo.org> wrote: > The REST API exposes metadata attributes in both JSON and XML formats, so it > could be argued that either format is equally convenient. I think the big > problem is documentation though - without digging into GeoServer's code is > it possible to figure out what keys to use and what the values should look > like? > > When I work with the REST API I often find myself making a configuration > through the web UI so I can get a "template" object. This is ok as far as > it goes, but I'm never confident I know about the acceptable range of values > for a setting, etc. That goes double when the value is some complicated > object instead of a simple string. > > Just throwing it out there.
Yeah, the concern makes complete sense. My hope is (with proper documentation) this makes it simpler. Like in if you want to configure a cached layer through the REST API, you should use the GWC REST API. And the way to do that is by having a steady xml/json representation of it. Storing it on the layer's metadata is a (very) convenient way of avoiding an extra storage mechanism for such a tightly coupled resource. But still I think the proper way to configure a cached layer for a geoserver layer would be through the gwc api. Makes sense? Cheers, Gabriel ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
