Data provider: define how API should be server

[nicola]

Something of this kind:

/api/v1/data/:datasource/?from=:date_from&to=:date_too

Define the schema of data as well

[nicola]

This circularly depends from conversations in #5. Yes we might use a service like Firebase, but are we proxying it or not @himerzi?

Do we need this design?

[himerzi]

My understanding is that we'd only need our own API insofar as we're storing data on our DB that either isn't available from the TFL API (otherwise, why not call the TFL API directly on the client side?), or can't be easily generated/processed on the client side. And further, if for the purposes of demonstrating our hypothesis, we don't need to use a real-time data feed, and all we need is some precompiled time-series data, then why don't we just store that data we need on the client-side, and relieve ourselves of having to build any kind of web-service.

We might still need a database for querying, and other sophisticated things, in order to build our dataset but once we've created the data that the visualisation will run off of, why not just hard-code it on the client-side viz code?

@nicola thoughts?

[navidhg]

@himerzi I agree - the focus should be on having a normalised way of storing all the data. I think the master database should be some form of SQL, so obviously working on the table structure would be the next immediate step (this shouldn't take too long). Our 'API' could be done through a tiny application sitting between the database and the user that accepts a SQL query as input and returns the result in a JSON file format - this is a pretty trivial application to write.

[nicola]

@navidhg, mmm I think there is something hot on #5 about database choice. @himerzi I just realised that whether we will be using firebase or not, we will still need to do some api eventually for post-processing the data or pre-processing real time data, so we will eventually need some server apis.

[nicola]

we liked this idea