We need an API to act as a controller receiving map requests, calling generation code, and returning generated map.

Why an API?

Tasacora main entry point will be a web rich applicative client.

If we use API, we gain more flexibility: for example, we could also provide a CLI client to be able to use Tasacora from a terminal without any need to install nina.

And we also allow third party to use it.

Documentation first

Plan is to use Open API / Swagger specification to define a REST API.

From there, we'll provide filler code to perform tasks.

Swagger utilities are able to generate documentation and tests.

This will directly get a very clear insight about the tasks Tasacora can perform and what we need to develop.

The Swagger way

We'll define a YAML document which respects the OpenAPI Specification.

There is an editor provided at http://editor.swagger.io/ to achieve this and see the documentation is real time.

Roadmap: where we'll go from there?

Once we have a working API implementation, we can work on two basis:

• at front-end level, to produce a website able to use the API
• at back-end level, @rama will revisit its codebase and release a Python 3 module and a CLI client to perform tasks already developed in rTASACORAEX

These two developments will be able to evolve in parallel: for example, the filler code will offer a sample thematic map, so front-end can focus on the UI, regardless the API can or not use rTASACORAEX code.