Create HTTP API

[epost]

Let's stick a simple HTTP API on top of this.

Proposal: put this in a dir http/ in addition to cli/, doc/, etc.

(Let's also consider for a second doing this using a petrinet and typedefs, because it's such a simple use case, although we don't want it to hinder progress.)

Ryan comments:

Both Java AQL and Haskell AQL support reading an AQL file on stdin and emitting HTML/text out.

[marcosh]

@epost which endpoints did you have in mind exactly? just one which exposes via HTTP the CLI behaviour?

Do you have in mind a specific web framework?

[wisnesky]

For the record, the current web interface for AQL is here: https://categoricaldata.net/tryaql.html

…

On Oct 18, 2018, at 3:00 AM, Marco Perone ***@***.***> wrote: @epost which endpoints did you have in mind exactly? just one which exposes via HTTP the CLI behaviour? Do you have in mind a specific web framework? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[epost]

@marcosh For now, a web version of the CLI seems like a decent place to start. I don't have any particular framework in mind yet; recommendations are welcome. We do work closely with Arian van Putten of Servant fame, and I'd be interested to look into that too, esp. considering our Typedefs work, but I'm not sure how suitable that is for this use case.

[marcosh]

At the moment, if the signature of the endopoint is String -> String, Servant looks a bit too heavyweight for the task. But, if we would like to evolve to a more typed version, it could definitely be more future proof. Other pros for Servant: it is the the web framework I'm more used to and it gives you endpoint documentation almost for free, which is super cool for a public API.

On the other hand, if we want to start with something simpler, we could use https://hackage.haskell.org/package/scotty-0.11.1