Yeah, the api is quite raw in some places and lacks convenience. Deleting is hard because you have to navigate through the relationships.
I would love to make that easier but it is always a fine line between convenience and keeping the api clean and "restful". On 10-07-16 7:38 AM, Arne Kepp wrote: > I haven't really been paying attention to trunk, so it's possible my > comments are completely off target: > > In 2.0.2 it is a bit asymmetric. If I want to add a Postgis layer from > scratch, I have to > 1) create a namespace > 2) create a datastore > 3) create a feature type > > But then to remove the same stuff > 1) drop layer<- huh ? > 2) drop feature type > 3) drop datastore > 4) drop namespace > > And it took me a bit of time to figure out that I didn't want to touch > the workspaces at all (or do I? They are given a lot of attention in the > documentation). > > I think it's a great tool, and the traffic on the list suggests many > others think so too. But will this make the resource / publishing split > harder, if you have an API resting (npi) heavily on the old structure? > > -Arne > > > On 7/15/10 10:12 PM, Chris Holmes wrote: >> Hey what do people think about making RESTConfig a default part of >> GeoServer for the 2.1.x release? I think it's one of the most popular >> modules, and could be helpful if people didn't have to install it. >> Checking the stats it edges out Oracle for the most popular in both >> 2.0.1 and 2.0.2. >> >> I think the one thing we need to do to bring it in to core is actual >> version the API. Putting it in core means we should commit to the API, >> and not break clients at all if we want to make incompatible changes. See >> >> http://barelyenough.org/blog/2008/05/versioning-rest-web-services/ >> http://stackoverflow.com/questions/389169/best-practices-for-api-versioning >> http://resources.esri.com/help/9.3/arcgisserver/apis/rest/versioning.html >> >> It seems like most people are pretty happy with the current API, but we >> should do some searching of feedback and get another round, to make sure >> it's an API we feel good about. >> >> Chris >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by Sprint >> What will you do first with EVO, the first 4G phone? >> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >> _______________________________________________ >> Geoserver-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
