[Geoserver-devel] REST config integrated for 2.1.x?

GeoServer GeoServer Developer
1

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

2

HI Chris:

I thought we mentioned this a couple months ago? I am fine with
bringing the REST module into core (earlier i asked if needed to be
integrated into one of the existing module or remain its own thing and
the answer was it should remain its own thing).

As for committing to an API - yes that would need to happen for it it
be brought in. Although that can be tempered with versioning an API so
clients can tell what they are up against.

Questions about the REST api remain popular; I am not suer if that
indicates a problem with the API or a problem with the documentation?
My hope is it indicates that the module is indeed popular.

Jody

On Fri, Jul 16, 2010 at 6:12 AM, Chris Holmes <cholmes@anonymised.com> 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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

3

  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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

4

I think it makes sense. And I like the of using a version parameter to handle version negotiation. Seems like it would be easiest way to go given how restconfig is structured.

On 10-07-15 2: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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

5

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
Geoserver-devel@lists.sourceforge.net
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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

6

Justin Deoliveira wrote:

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".

Btw, the GUI has these nice cascade delete visitors that can be used.
Maybe using a special HTTP header to ask for the cascaded deletion is
the way to go?

Cheers
Andrea