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:


In the above url the following parameters are implied:




SSL Encryption

http:// or https://

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



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



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


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.



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:




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


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


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:


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