Issue 27 in georest: Ability to interrogate configured MapGuide Feature Sources over HTTP
geo...@googlecode.com
Owner: jumpinja...@gmail.com
Labels: Type-Enhancement Priority-Medium
New issue 27 by jumpinja...@gmail.com: Ability to interrogate configured
MapGuide Feature Sources over HTTP
http://code.google.com/p/georest/issues/detail?id=27
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)
geo...@googlecode.com
Cc: hkurta...@gmail.com
Comment #2 on issue 27 by ja...@jasonbirch.com: Ability to interrogate
configured MapGuide Feature Sources over HTTP
http://code.google.com/p/georest/issues/detail?id=27
(No comment was entered for this change.)
geo...@googlecode.com
Comment #1 on issue 27 by ja...@jasonbirch.com: Ability to interrogate
http://code.google.com/p/georest/issues/detail?id=27
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.