[GRASS-dev] Implement a REST API for GRASS

[Pietro]

Dear devs,

In the last days I've started thinking to a REST API
<https://en.wikipedia.org/wiki/Representational_state_transfer> for GRASS.
I think would be nice to offer some of the GRASS functionalities through a
web service.

I would like to detailed the whole REST API using the YAML
<http://www.yaml.org/> format following the Swagger <http://swagger.io>
specifications/services, but before start the real work I would like to
receive feedback on the idea...

- first of all: is build a REST API for GRASS a stupid idea? should we
use/promote just the WPS?
- I've started a first conceptual draft of a possible API available at this
repository:
https://github.com/HotMaps/GRASS-rest/blob/master/swagger/grass_gis_concept.yaml,
the file is just a sketch of what the API could looks like/do (and is not
yet compliant/usable with Swagger).

I've tried to synthesize the concept in README
<https://github.com/HotMaps/GRASS-rest/blob/master/README.md> let me know
if you have comments and ideas, please feel free to open new issues or pull
requests.

I see a major issue that is that: GRASS is using unix permissions to define
the rules on who can access on what.
To preserve this part, the REST service must be executed as super-user in
order to be able to execute a module as the owner of a specific mapset and
all the user of the platform must be also user of the system.
The other option that I see is to execute the service as a normal user of
the system who is the owner of all the gisbase, locations and mapsets, and
the permission are checked before the execution of each module. The
permission check must be implemented in a new layer on top of GRASS. With
this solution the user of the platform are different from the user and
group of the system.

Any ideas that you want to share?

Best regards

Pietro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20170524/53ed417a/attachment.html>