Child pages
  • Metrics API
Skip to end of metadata
Go to start of metadata

High-level description

The API will divided into two parts – the read and the write.

  1. Aggregator -> Backend
  2. Frontend -> Backend

The backend will implement the API and the aggregator and the frontend will be the clients.

Implementation

For the first iteration, the API will use HTTP as the protocol and JSON as the wire format.

Types

DateTime -> This will be encoded as the POSIX time.
Time -> A positive number in minutes.
Number -> A number
String -> A string

Difference between a `field` and an `attribute`

A field has a numerical value, making it graph-able. On the other hand, an attribute is string – which cannot be graphed – but we can filter the dataset based on the attributes (i.e. graph lab usage of Linux machines only).

Frontend -> Backend

Request

{
    "namespace": String,
    "start_time": DateTime,
    "end_time": DateTime,
    "interval": Time,
    "fields": (Listof String), # The field names will be formatted as namespace.fieldname
                               # or fieldname (and the given namespace will be used).
    attribute1: String, # We will filter the dataset via the attributes
    attribute2: String,
}

Response

Success case:

{
    "request": Request,
    "code": "success",
    "response": [{
        field1: Number,
        field2: Number,
        namespace.field1: Number,
        ...
    }, {
        ...
    }]
}

Error case:

{
    "request": Request,
    "code": Number,
    "error": "Error message"
}

Aggregator -> Backend

Request

{
    "namespace": String,
    "apikey": String, (should be abstracted out by the api module)
    "timestamp": DateTime,
    attribute1: String,
    field1: Number,
    field2: Number,
    field3: Number,
    ...
}

Response

{
    "code": Number,
    (optional) "error": String, # The error message
}

Response Codes

code

semantics

201

Created

400

Bad Request

503

Service Unavailable

  • No labels