Integrate reviewer \w REST API

[bzz]

As soon as there is a

• REST API for feature extraction https://github.com/src-d/backlog/issues/1202
• UASTs are stored in DB Receive and store serialized ProtoBuf \w UAST as part of the input #197 → Add UAST to old FilePairs #214

we would need to call an instance of this REST API through a configurable URL.

REST API input:

• 2 UASTs (optional)

REST API output:

• data that need to be shown in reviewer UI

Preliminary suggested by @vmarkovtsev JSON in details

[
{
    "tab": "first scheme",
    "object1": [
        {"feature": "name1", "type": "number", "value": 100500},
        {"feature": "name2", "type": "hash", "value": "abcdef0123456789"}
    ],
    "object2": [
        {"feature": "name1", "type": "number", "value": 100501},
        {"feature": "name2", "type": "hash", "value": "abcdef1234567890"}
    ],
    "pair": [
        {"feature": "score", "type": "number", "value": 0.95}
    ],
}, {
    "tab": "second scheme",
    "object1": [
        {"feature": "name1", "type": "number", "value": 100500},
        {"feature": "name2", "type": "hash", "value": "abcdef0123456789"}
    ],
    "object2": [
        {"feature": "name1", "type": "number", "value": 100501},
        {"feature": "name2", "type": "hash", "value": "abcdef1234567890"}
    ],
    "pair": [
        {"feature": "score", "type": "number", "value": 0.95}
    ],
}
]

but @mcuadros suggested using a simple structure, that as much as possible can be just "shown" or printed in the reviewer UI.

Part of this issue is to determine this simplest-possible, but extensible format.

[dpordomingo]

As talked irl with @bzz UAST will be an optional data in the CAT internal database

[dpordomingo]

From our meetings we understood that:

• the payload sent to the API will be the two UAST stored in the internal DB for the FilePair,
• the current UI would be kept if the data to represent fits on it,
• if the data to represent does not fit the current UI, it will be printed as it comes from the API,

Considering the assertions above, in order to use the current UI, the API Response schema should be:

type FilePairFeatures {
    Object1 []Feature
    Object2 []Feature
    Pair Feature
}

type Feature {
    Name string
    Value float32
}

This schema fits the proposed by @vadim but has the following modifications:

• A Feature has not type → it is always a float number,
• The FilePairFeatures.Pair will be only one Feature, and represents the current "similarity score",
• A FilePair should have only one* FilePairFeatures element;

*If it is needed more than one FilePairFeatures elements per FilePair, or different Feature types, it might be done with the current UI, but it would depend on further clarifications.

[dpordomingo]

This issue was changed to blocked, waiting for the Feature Extractor API, hopefully following the schema defined by #198 (comment)