alexasahis / georest

Automatically exported from code.google.com/p/georest
0 stars 0 forks source link

Ability to interrogate configured MapGuide Feature Sources over HTTP #27

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
I'm currently brainstorming this idea of adding feature create/update/delete 
support through the standard MapGuide Maestro HTTP connection if an additional 
GeoRestUrl property is specified.

Now for this to work, Maestro would have to know which Feature Sources are 
updateable via GeoREST. Thus, GeoREST would have to expose some HTTP endpoint 
that returns a list of the following information:

 * Feature Source ID
 * Can Insert data?
 * Can Update data?
 * Can Delete data?

With this list, the Maestro HTTP connection would have enough information to 
guard against illegal actions (eg. Inserting into Feature Source that is not 
configured, or updating a Feature Source that is not configured for updates)

Original issue reported on code.google.com by jumpinja...@gmail.com on 9 Jan 2012 at 3:10

GoogleCodeExporter commented 8 years ago
This sounds like a cool idea.  I actually thought we already had something like 
that, but it may just be for the OData support (/$metadata request)

I wonder if this would be best at the base URL for the service (/rest/data/, 
with XML, JSON, and templatable HTML results), or as a sidebar (/rest/config/ 
or something like that).  I'm leaning towards the former.  If we did go with 
the former, it would be a great starting point for metadata publishing as well; 
the config file could eventually be extended with things like title, 
definition, author, accuracy, etc...

As part of this, I would like to see an extension to the Resource and 
Representation entities that flags them as "hidden" from the service 
description.  I'm relying on obscurity for a couple services that I want to use 
internal to templates (as joined feature sources) but which I wouldn't want to 
publish and support for external use.

There are a few different levels where editability is controlled, from HTTP 
protocols supported in the GeoREST config, through readonly flag on FDO data 
source, to underlying RDBMS permissions. I'm guessing that this feature would 
only take into account the GeoREST configuration.

Original comment by ja...@jasonbirch.com on 9 Jan 2012 at 7:13

GoogleCodeExporter commented 8 years ago

Original comment by ja...@jasonbirch.com on 9 Jan 2012 at 7:14