RFC: API restructuring

[blootsvoets]

The API is not completely consistent, and not all calls are very REST-like. It also includes things that could be query parameters. From a REST point of view, a possible API ordering would be:

Get a list of projects: GET /api/projects

Get all subjects in a project GET /api/projects/{projectId}/subjects

Get the information on a single subject GET /api/subjects/{subjectId}

Get information on what sources a subject has GET /api/subjects/{subjectId}/sources

Get raw data from a given source. Not all sources may have this available, but for example monitors will. In the future, we might include for example the last day of data in this measure, or even query HDFS for it. GET /api/data/{userId}/sources/{sourceId}/{sourceData}?startTime={startTime}&endTime={endTime}

Get aggregated data of a given source datatype. Statistic could be min, max, etc. GET /api/data/{userId}/sources/{sourceId}/{sourceData}/{statistic}?timeWindow={timeWindow}&startTime={startTime}&endTime={endTime}

Get the latest aggregated data of a given sensor: GET /api/data/{userId}/sources/{sourceId}/{sourceData}/{statistic}/latest?timeWindow={timeWindow}

Aggregate the data of multiple sources. For example, one statistic could be DISTINCT, which counts the active number of sensors that are available for any given timeWindow. Another could be avg over multiple heart rate sensors. POST /api/data/{userId}/aggregate/{statistic}?timeWindow={timeWindow}&startTime={startTime}&endTime={endTime}

Timewise, this probably cannot be included in the next release.

Please comment @herkulano @afolarin @yatharthranjan or others.

Edit: path parameter in POST query included as per comment of @herkulano Edit: merged monitors into sources as just a type of source, as suggested during the call Edit: clarified the use of aggregate.

[herkulano]

@blootsvoets Looks great! 💯

Should statistic be included here as path parameter?

Is the path param query only set for the "distinct number of streams per time period"? If so then don't think we need to set the stat here, and maybe query could have a name more associated with the data, for example, distinct. If not and this is a generic call then yes, it's better to define it.

[afolarin]

Hi Joris, this looks good to me. Agree prior implementation wasn't strongly RESTful.

Get the distinct number of streams per time period as in #39. POST /api/data/{userId}/aggregate/{statistic}?timeWindow={timeWindow}&startTime={startTime}&endTime={endTime} Should statistic be included here as path parameter? on @herkulano point by statistic you mean COUNT in this instance (would there ever be others e.g. aggregators min, max, avg, iqr, etc)?

[blootsvoets]

Indeed, I've clarified the call in the above post.

[yatharthranjan]

Looks good. 🖒

[nivemaham]

Closed by #89