Re: [Geoserver-devel] GSIP-137 ResourceStore REST API Proposal

Page updated, totalling up the numbers has this one passed: https://github.com/geoserver/geoserver/wiki/GSIP-137 Hopefully the work can get in before the Feb 18th cut-off. -- Jody Garnett On 26 January 2016 at 13:51, Jody Garnett wrote: > Here is the proposal from

Re: [Geoserver-devel] GSIP-137 ResourceStore REST API Proposal

On 09/02/16 08:14, Robert Coup wrote: > fyi, the "X-" prefix for custom headers is not the recommended approach any > more... http://tools.ietf.org/html/rfc6648#section-3 > *Recommendations for Creators of New Parameters* > Creators of new parameters to be used in the context of >> application

Re: [Geoserver-devel] GSIP-137 ResourceStore REST API Proposal

I think custom headers are fine, it's just that if someone is using them in practice they'll know to expect them :) RESTful directories (IMO) should be self-documenting: the parent of /a/b/c is /a/b and so on... AFAICT there's nothing special in the metadata proposal that couldn't be dealt with

Re: [Geoserver-devel] GSIP-137 ResourceStore REST API Proposal

On 3 February 2016 at 23:46, Niels Charlier wrote: > > - Instead of metadata, it would be (arguably) more RESTful to support > > a HEAD operation. You have a header for Last-Modified, could add an > > X-Parent and X-Type, and name could be deduced from the URL. Or is the > >

Re: [Geoserver-devel] GSIP-137 ResourceStore REST API Proposal

HI Ben, Thanks for your review! On 02/02/2016 08:37 PM, Ben Caradoc-Davies wrote: > +1. Looking pretty good. Observations: Cool thanks, that makes it approved then. > > - Instead of metadata, it would be (arguably) more RESTful to support > a HEAD operation. You have a header for Last-Modified,

Re: [Geoserver-devel] GSIP-137 ResourceStore REST API Proposal

+1. Looking pretty good. Observations: - Instead of metadata, it would be (arguably) more RESTful to support a HEAD operation. You have a header for Last-Modified, could add an X-Parent and X-Type, and name could be deduced from the URL. Or is the need for custom HTTP headers a red flag? (Not

Re: [Geoserver-devel] GSIP-137 ResourceStore REST API Proposal

On 30-01-16 12:08, Andrea Aime wrote: The ResourceMetadata xml representation should be follow the same resource interlinking approach as our main REST API, for example: Modified. I'd remove POST, two ways to do exactly the same things seem redundant to me, not sure what other think...

Re: [Geoserver-devel] GSIP-137 ResourceStore REST API Proposal

On Tue, Feb 2, 2016 at 11:26 AM, Niels Charlier wrote: > Writing the above I actually raised one more question: what happens if > someone > goes and chances configuration files using the resource REST api? > It's ok to say "it's store implementation dependent", but at least we >

Re: [Geoserver-devel] GSIP-137 ResourceStore REST API Proposal

Hmmm, I still find it difficult to understand your point. If you are using JDBCConfig, the catalog .xml files become meaningless, are ignored and changing them never has any effect. There is no difference there whether you are using jdbcstore or not. As far as I see it, changing a config

Re: [Geoserver-devel] GSIP-137 ResourceStore REST API Proposal

Geoserver will kind of notice in both cases - icons are cached so will not pick up on a change unless we add a watcher (or until as you say the next reload). Things like security that already have a watcher will be noticed in both cases. We should put this off until we look at notification -

Re: [Geoserver-devel] GSIP-137 ResourceStore REST API Proposal

On Tue, Feb 2, 2016 at 11:54 AM, Niels Charlier wrote: > Hmmm, I still find it difficult to understand your point. > > If you are using JDBCConfig, the catalog .xml files become meaningless, > are ignored and changing them never has any effect. There is no difference > there

Re: [Geoserver-devel] GSIP-137 ResourceStore REST API Proposal

On Wed, Jan 27, 2016 at 5:11 PM, Jody Garnett wrote: > Thanks Andrea, all good feedback - these proposals end up being design > documents after all. > > I don't think I know enough about how rest path mappers work to > understand the difference between config and data.

Re: [Geoserver-devel] GSIP-137 ResourceStore REST API Proposal

Andrea, have I addressed your questions well enough with my changes? Do we agree on removing POST altogether (have not yet changed this in the proposal yet)? Niels On 27-01-16 11:29, Niels Charlier wrote: > Hi Andrea, > > Thanks for your review. > > On 27-01-16 10:48, Andrea Aime wrote: >> Hi

Re: [Geoserver-devel] GSIP-137 ResourceStore REST API Proposal

Hi Niels, I'm sorry, still haven't had time to review your changes. I'll be fully packed till evening today too, but I'll make sure to review everything during the weekend Cheers Andrea On Fri, Jan 29, 2016 at 1:57 PM, Niels Charlier wrote: > Andrea, have I addressed your

Re: [Geoserver-devel] GSIP-137 ResourceStore REST API Proposal

Thanks Andrea, all good feedback - these proposals end up being design documents after all. I don't think I know enough about how rest path mappers work to understand the difference between config and data. Internally the ResourceStoreAPI is used to access config, and a different

Re: [Geoserver-devel] GSIP-137 ResourceStore REST API Proposal

Hi Jody, -1 for the moment, but only because the proposal is incomplete. Bits that should be addressed before making it go forward: * Show the XML and JSON representations of the various resources and commands (are they properly interlinked via atom links, and what other information do they

Re: [Geoserver-devel] GSIP-137 ResourceStore REST API Proposal

I have read the email thread and the proposal. +1 on the new functionality. == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Alessio Fabiani @alfa7691 Founder/Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054

Re: [Geoserver-devel] GSIP-137 ResourceStore REST API Proposal

Hi Andrea, Thanks for your review. On 27-01-16 10:48, Andrea Aime wrote: > Hi Jody, > -1 for the moment, but only because the proposal is incomplete. > > Bits that should be addressed before making it go forward: > * Show the XML and JSON representations of the various resources and > commands

[Geoserver-devel] GSIP-137 ResourceStore REST API Proposal

Here is the proposal from Niels: https://github.com/geoserver/geoserver/wiki/GSIP-137 +1 the proposal has been revised addressing my earlier questions. -- Jody Garnett -- Site24x7 APM Insight: Get Deep Visibility into