1) HTTP Endpoint Request Payload and Switching

This Blog entry is from the Getting Started in Jube section in Learn Jube.

The Jube Platform does not have a hard-coded API specification and the HTTP Endpoint is promiscuous in the format of the GET or POST body that it accepts, with that POST body being parsed as per a specification configured in each Symbol or Entity model.

The POST body may be XML or JSON, in any structure, with its precise structure being configured in the Entity or Symbol model definition of Jube. It of course follows that the XML or JSON should pass a parse on receipt of the POST, appropriate to the specification. When the Jube Engine receives a HTTP request, the POST body is not initially inspected or parsed, instead only the Query String of the HTTP request is inspected for the presence of switching keys.

An example of a HTTP request to the Jube Engine is as follows:

http://api.jube.io:5555?EntityAnalysisModelGUID=253e427e-4523-40d2-b155-fcd5348e20e9

In the above url the following parameters are implied:

Component

Text

Description

SSL Encryption

http:// or https://

The http SSL designator which is used to encrypt HTTP traffic using SSL.

Endpoint

api.jube.io

The IP address or sub domain name for which HTTP posts are to be made.

Port

:443

The colon designating a nonstandard port to be used, followed by the port.

This is not needed, but is included for completeness.

Query String Delineation

?

The model to be invoked for the purposes of processing the POST body is passed in the query string, everything that follows the ? will be considered model parameters.

Model Type Switch

EntityAnalysisModelGUID=

While there are several parameters available in model recall, such as the ability to process a model asynchronously, for the purposes of this document there is a single parameter of EntityAnalysisModelGUID which, by virtue of its presence, switches to the entity subsystem and will seek a GUID as follows.

GUID

253e427e-4523-40d2-b155-fcd5348e20e9

The GUID of the model, created automatically on model insert.

Switching, depending up the presence of a given Switch key, takes place in the following order:

Switch

Description

Symbol

A switch to be made to the Symbol Subsystem to process a new Symbol (e.g. Stock Price).

ExhaustiveSearchInstanceGUID

A switch to be made to the Exhaustive Subsystem to recall a trained model, bypassing the Entity Model and Symbol Model processing.

EntityAnalysisModelGUID

A switch to be made to the Entity Subsystem to process a new Entity (e.g. Account Transaction).

EntityAnalysisModelGUID and Tag

A switch to be made to process a Tag for a given transaction previously processed through an Entity Model.

Although the endpoint for all requests made to Jube is the same, the processing is very different depending upon the switch.

Jube has several pre-configured models for the purposes of validation, integration testing and confidence building. These pre-configured models will be explored in subsequent Blog entries. The pre-configured models and example switches and formats are contained in the formats document as follows:

http://download.jube.io/formats.pdf

The formats document provides examples of messages routed by each switch set out above.