Web API

webapi

The TIOBE TICS Web API is the public programming interface for the TICS viewer. It exposes the same metric data that the viewer uses, allowing you to integrate TICS data in your own management dashboard or reporting software.

The API follows a RESTful design, meaning that you use stateless HTTP methods to request data. By using the HTTP protocol, you are not bound to a particular programming language or platform to consume the API. We recommend using a standard HTTP client library that is available for your platform.

HTTP Requests

Data is queried using an HTTP GET request on a particular URL. You can use a standard browser to experiment with the API. For example, to get the last measured value for the TIOBE Quality Indicator metric for project use the following URL:

 

The URL has the following variables:

 
The host name and port on which the TICS viewer runs.
 
The section that you want to request data for. In a default TICS installation there is only one section named TICS.
/v1
Indicates which version of the API you want to use. The version number is increased every time we have to make a backwards incompatible change to the API. This ensures that consumers of the old API do not break. New fields will be added to the API without increasing the version number, as this will not break existing consumers.
/Measure
The name of the API that you want to query. In this case the Measure API is consulted, which provides metric value data.
?metrics=tqi&filters=Project()
The part after '?' is called the query-string part of the URL and contains the API parameters. Each parameter is specified using a name=value pair. Multiple parameters are joined using '&'. Unrecognized parameters are silently ignored.
URLs should be encoded using percent encoding (%20 for spaces, %2B for +, etc).

HTTP Response

If the request HTTP is valid and can be performed without problems, the API will return an HTTP status 200 response. The body of this response contains the requested data in JSON format. For the call above, this will look something like this:

{
  "data": [
    {
      "value": 77.39341858450899,
      "formattedValue": "77.39%",
      "letter": "C"
    }
  ],
  "metrics": [
    {
      "expression": "tqi",
      "fullName": "TQI"
    }
  ],
  "nodes": [
    {
      "name": "trunk",
      "fullPath": ""
    }
  ],
  "dates": [
    "2014-02-01T16:19:09.000+01:00"
  ]
}
"Data", "metrics", "nodes", etc. are JSON object fields. The response is guaranteed to contain at least these fields, but might contain more when we add functionality to the API later. As such, you should not attempt to interpret the response by assuming the value you need is on a certain line or column number, or by using regular expressions! You should also not assume that the fields of the JSON object are in a specific order. You should only interpret the response by running it through a JSON parser and accessing the documented fields of the resulting JSON object. We recommend using a standard library for JSON parsing, such as Gson for Java, or the json library in Python.

If something went wrong, the status code 400 is used to indicate "expected errors". An example of an expected error is when you request data for a non-existent project. Status code 500 is used for unexpected errors. In this case, contact us and provide the resulting stack trace.

API Endpoints

The available API endpoints are now discussed in detail. For each endpoint we describe the input parameters that it accepts and the fields in the JSON output. Multiple values for an input parameter can be separated using commas (,). Parameter names and values are case-sensitive.

Currently there are three public endpoints available:

Measure API

Use the Measure API to obtain (aggregated) metric values for specific folders or files at a specific date. Use the following URL:

GET 

The input parameters are:

Parameter Value Required Description
metrics metric expression yes

A list of metrics for which you want to obtain data. For example, use metrics=tqi to obtain the metric values for the TIOBE Quality Indicator or metrics=loc,eloc to get the metric values for both the Lines of Code and Effective Lines of Code metrics.

A list of commonly used metrics can be found here. Unrecognized identifiers will be silently ignored: the response will not contain any data for it and no error will be generated.

filters filter expression no
  • Since version: 8.4

The filters to apply when retrieving data. For example, use filters=Project(foo),Sub(src),Sub(main) to keep only measurements from subsystem src/main in project foo. To query data on a specific date, use the Date(…) filter. More information about filter expressions is found here.

Measurements are aggregated using the metric's intrinsic aggregation function. You cannot control the aggregation function via the API. As it does usually not make sense to aggregate data over different branches from the same project, the API takes only measurements from the "default" branch when no branch is specified.

This parameter is optional; when you omit it (and do not use the deprecated nodes parameter), the most current data from all projects is aggregated into one metric value.

nodes (or paths) path expression no
Deprecated Please use the more powerful filters parameter instead. Although this parameter is deprecated, it will remain supported for backwards compatibility.

A list of paths for which you want obtain data. A path identifies a node in the tree representing your archive's hierarchy of folders and source files. For example, use nodes=HIE:////path/to/file.cpp to get data for file.cpp in branch "" in .

A path literal is a combination of a hierarchy specifier (HIE or ORG), followed by '://', and then followed by a '/'-separated list of names. The first name is always the project name, the second name is the branch name. The remaining names denote folders. The last name can denote a file. For example, HIE://MYPROJECT/trunk/path/to/file.cpp denotes file named "file.cpp" in folder "path/to" in branch "trunk", project "MYPROJECT". HIE://MYPROJECT/trunk denotes the root folder in the branch. ORG://MYPROJECT/trunk denotes the root folder of the same branch in the ORG hierarchy. The ORG hierarchy is only available if you have configured this view for your project.

dates date expression no
Deprecated Please use the Date() filter in the filters parameter instead. Although this parameter is deprecated, it will remain supported for backwards compatibility.

One or more dates for which you want to obtain data. If omitted, the last TICS measurement date (for the respective project) is used. The requested date does not need to coincide with a measurement date. In that case, the metric value for the immediately preceding measurement date will be returned.

The date format follows the ISO 8601 standard: YYYY-MM-DDThh:mmTZD, where TZD is the time zone designator (Z for UTC or +hh:mm or -hh:mm). For example, use dates=2013-02-01T00:00Z to get data for February 1, 2013 at midnight in the UTC time zone. It is recommended that you specify the time zone explicitly. If the time zone is omitted, the time is considered local to the server on which the TICS Viewer runs.

The JSON output fields are:

Field Description
metrics

An array of metric objects for which data is available in the data field. These objects have the following fields:

NameValue
expression The unique identifier for this metric. Example: loc.
fullName The human-readable name for this metric, as it is displayed in the viewer. Example: Lines of Code.
projectGroup An JSON object containing a field named elements that is an array of nested project groups pertaining to this metric value. This field is only present when a project group filter is used.
nodes

An array of path objects for which data is available in the data field.

A path object denotes a node in a particular view on the source tree and has the following fields:

NameValue
name The simple name of the path, e.g. file.cpp
fullPath The full path name, e.g. HIE:////path/to/file.cpp
Limitation: You cannot query data for paths referring to multiple projects. You need to split the API call up so that each call refers to only one project.
dates

An array of stringified timestamps for which data is available in the data field, in ISO 8601 format. The time zone used is that of the viewer's machine. Example: 2014-02-07T16:19:09.000+01:00. If the optional "dates" input parameter was omitted, this array contains a single item: the timestamp of the last TICS run for the respective project.

data

An array containing the requested metric value objects. These objects have the following fields:

NameValue
value The unformatted metric value as a JSON number. Depending on the metric, this will be an integer (e.g., for lines of code), a floating point value (e.g., for average cyclomatic complexity) or a list of objects (e.g., for runs).
letter If applicable, contains the TQI score (A, B, C, D, E, or F), otherwise null.
formattedValue The formatted metric value is a string representation of the metric value. It uses the same formatting as the viewer and can therefore change between versions. It can contain HTML, for instance for delta metrics or when the metric value could not be determined due to analysis errors. Therefore, do not attempt to interpret the value or do computations with it. Use the value for that instead.
The data array contains a metric value object per metric, date, and node combination, and thus contains |metrics| × |dates| × |nodes| elements. Pseudo-code for iterating over the data array:
var idx = 0;
foreach(metric in json.metrics) {
  foreach(date in json.dates) {
    foreach(node in json.nodes) {
      var metricValue = json.data[idx];
      console.log('Value for metric %s, node %s at %s is %s', metric.fullName, node.fullPath, date, metricValue.formattedValue);
      idx += 1;
    }
  }
}
Note that you should iterate over the actual objects present in the metrics, dates, and nodes fields of the response, and not over the input parameters.

ToImage API

Use the ToImage endpoint to download the TQI Label as an image (png format) programmatically, or to embed the TQI Label in your own webpage:

GET 

To obtain a URL that you can use in your own application, go to the Dashboard and select the project and/or filters that you want to generate a TQI Label for. Then, right click the Download Image button beneath the TQI Label and choose "copy link address". You can use this URL in your application to download the TQI Label with the most actual data.

The parameters of the ToImage API are:

Parameter Value Required Description
url base64 encoded URL (relative) yes The easiest way to determine this parameter is to follow the steps above. You can also generate it programmatically by base64 encoding the following (relative) URL: TqiLabel.html#axes=Project(MYPROJECT)&print=true, where MYPROJECT should be replaced by the project name that you want to generate the label for.
disposition attachment or inline No (default=inline) The disposition type used by the HTTP response. Use the value attachment to indicate that the browser should prompt the user to save the response locally. Use the value inline to have the browser process the response normally (as per its media type), which can be used to embed the image in your dashboard (e.g. using an IFRAME).
filename name of file, ending with .png Only when disposition is set to attachment The default filename to be used by the browser when disposition is attachment. The filename should end in .png.
zoom The zoom factor No (default=1) Use this to generate a higher-resolution image (up to 4 times).

If you have configured authentication, you have to provide the required credentials using Basic HTTP Authentication. For instance, if you are using the GNU tool wget, you can provide a username and password as follows:

wget "ToImage?format=png&url=BASE64URL" --user USERNAME --password PASSWORD --auth-no-challenge -O TQILabel.png

Annotations API

Use the Annotations API to retrieve a list of all annotations for violations of a given type (Coding Standard Violations, Compiler Warnings, or Abstract Interpretation Violations) and for a certain project. For instance, the following URL returns a JSON object containing all Coding Standard violations for project :

GET 

The input parameters of the Annotations API are:

Parameter Value Required Description
metric One of Annotations(CS), Annotations(CW), Annotations(AI) yes Specifies whether to retrieve annotations for Coding Standards (Annotations(CS)), Compiler Warnings (Annotations(CW)), or Abstract Interpretation (Annotations(AI)).
filters filter expression Project(…) filter is mandatory

Specifies the filters that should be applied. All filters are optional except for the Project filter. The following filters are supported:

  • Project(…): only return annotations for this project.
  • Language(…): only return annotations for this language. The language should be specified using one of the built-in language identifiers.
  • Level(…),Category(…),Rule(…): only return annotations for given level, category, or rule.
  • Suppressions(…): whether suppressed violations should be included. Suppressed violations are omitted by default. Specify Suppressions(yes) to only get suppressed violations. Specify Suppressions(either) to get both suppressed and unsuppressed violations.
  • View(…): whether to retrieve annotations for the Hierarchical (View(HIE)), Organizational (View(ORG)), or Rational Rose (View(RR)) view (where configured). If omitted, the Hierarchical view is used.
  • Sub(…): only return annotations for the given subsystem. You can specify multiple Sub filters to specify a nested subsystem. For example, to get all annotations for the component comp in module mod in the organizational view of project X, you would use: Project(X),View(ORG),Sub(mod),Sub(comp).

The order in which you specify the filters is not important, except for the Sub filters.

The JSON output fields are:

Field Description
header

A JSON object containing meta-data about the response. Currently, it only contains a title field:

NameTypeValue
title string Comprehensive title describing which annotations are in the response. Do not rely on the specific contents of this string, as it might change in the future!
data

An array of Annotation objects that pass the given filters, in no particular order. Each object contains the following fields:

NameTypeValue
fullPath string The full path name, e.g. HIE:////path/to/file.cpp
line number The line number on which the violation occurred
level number The violation's level
category string The violation's category name
rule string The violation's rule name
msg string The message of the annotation
supp boolean Whether the violation is suppressed by the violation suppression mechanism or not. By default, only unsuppressed violations will be shown unless you specify a Suppression(…) filter (see above).
count number The number of violations that this annotation represents. This is usually 1. However, it sometimes happens that a code checker produces multiple violations with the exact same line number, rule, and message. This might happen for instance when there is a violation on a line produced by a C++ macro expansion.

The following fields are only present when applicable:

NameTypeValue
buildTargets array of string The build targets for which this violation holds. This field is omitted when the violation concerns all configured targets.
Warning: Depending on the number of annotations, the query can become slow and the response might become large. Consider adding filters such as a Language filter to prevent this.

Filter expressions

A filter is used to narrow down the data that you are interested in. Without any filters, a query aggregates all measurements across all projects into one metric value. A filter is specified using a case-sensitive filter expression, which has the form PropertyName(parameter). The property name determines what property of the measurement to filter on. The parameter specifies which measurements should pass the filter. For instance, Language(JAVA) is a filter that only keeps measurements that apply to Java files. Multiple filters can be specified by separating them using commas. For instance, Language(JAVA),CodeType(test) keeps measurements that apply to Java test files. See the table below for a list of available filters and examples.

Compound filters filters on a set of values, containing at least two elements. The are specified using a filter expression of the form PropertyName(Set(parameter,parameter[,...])). For instance, Language(Set(CPP,JAVA)) is a filter that keeps measurements that apply to C++ or Java files. In the breadcrumb, a compound filter is created when you check multiple checkboxes in a filter dropdown menu.

Groupers are a kind of filter that causes a query to produce more than one result. We distinguish between open and closed groupers; the difference is the number of parameters. An open grouper doesn't accept any parameters and has the form PropertyName(). It produces a metric value for each distinct property value it encounters. For instance, Language() produces a metric value per language that is encountered in the measurements. A closed grouper has at least two parameters: it produces a metric value for each parameter specified. For instance, Language(CS,JAVA) produces one metric value for C# and one for Java.

Below is an overview of supported filters that you can use with the API calls described here. The viewer uses other filters that are not described here, but that you can find in your browser's address bar when selecting the filter in the breadcrumb. However, we do not recommend that you use these undocumented filters as they might change in the future.

Escaping: Because the characters ,, (, and ) have a special purpose in expressions you need to escape them using a backslash if they occur in a parameter name (which you should encode as %5C in the URL).
Filter Description
Project(…)

Confines metric values to the given project(s). For example, to get the Lines of Code (loc) for a specific project:

 

To get the Lines of Code per project use:

 

Branch(…)

Confines metric values to the given branch. Should always be preceded by a Project filter. For example, to get the Lines of Code (loc) for a specific branch:

 
ProjectGroup(…)

Confines metric values to the given project group(s). For example, to get the Lines of Code per project group:

 

The projectGroup fields in the JSON output will contain the encountered project groups. To specify nested project groups, use multiple expressions: ProjectGroup(foo),ProjectGroup(bar).

Limitation: The Measure API will not give proper results for projects that are not inside a project group.
Sub(…)

Confines metric values to the given subsystem. Nested subsystems can be specified by using multiple expressions. When specifying a subsystem, you should also specify a Project filter. For example, to get the Lines of Code for a specific subsystem src/main/java in project foo in the Hierarchical view, use:

Measure?metrics=loc&filters=Project(foo),Sub(src),Sub(main),Sub(java)

When specifying a subsystem in another view that the hierarchical view, you need to specify a View filter. For instance, to get the Lines of Code for Team 2 as specified in the Organizational View, use:

Measure?metrics=loc&filters=View(ORG),Project(foo),Sub(Team 2)
File(…)

Confines metric values to given File. For example, to get the Lines of Code (loc) for all files in a project:

 
View(…)

This filter is needed when you use the Sub filter, and want to query subsystems from the Organizational (View(ORG)) or Rational Rose (View(RR)) view. When querying the Hierarchical view, the View(HIE) filter can be left out because it is implicit.

Language(…)

Confines metric values to the given programming language(s). Programming languages need to be specified using one of the built-in programming language identifiers. For example, to get the lines of code for Java:

 
Level(…)
Category(…)
Rule(…)

Confines violation metrics to a specific coding rule name, category, or level. For example, to get the coding standard violations for level 1 use:

 

Provide a comma-separated list of rule property values to create multiple metrics. For example, to get the coding standard violations for categories Basic and Design use:

 

Omit the parameter to split by all available property values. For example, to create a metric for each available rule:

 
Date(…)

The date for which to obtain data. If omitted, the last TICS measurement date (for the respective project(s)) is used. The requested date does not need to coincide with a measurement date. In that case, the metric value for the immediately preceding measurement date will be returned.

The date can be specified in two formats:

  1. In UNIX Epoch time format, which is the number of seconds that have elapsed since 1 January 1970 at 00:00 in the UTC time zone. For instance, specify Date(1359676800) for February 1, 2013 at midnight in the UTC time zone.
  2. In the ISO 8601 format: YYYY-MM-DDThh:mmTZD, where TZD is the time zone designator (Z for UTC or +hh:mm or -hh:mm). For example, use Date(2013-02-01T00:00Z) to get data for February 1, 2013 at midnight in the UTC time zone. It is recommended that you specify the time zone explicitly. If the time zone is omitted, the time is considered local to the server on which the TICS Viewer runs.

The UNIX epoch time is the canonical format: other formats will be automatically converted to it.

CodeType(…)
Since version 9.1

Confines metric values to the given code types. A code type of a file is either production, external, or test. When you do you not specify a CodeType filter, the filter CodeType(production) is implicitly used. To get all code for a project, including test and external code, use:

 

Information about configuring code types is found here

Authentication

The Web API respects any authentication that you might have configured in your SERVER.txt. If you try to acquire data for a project without providing proper credentials, the server responds with an HTTP status code 401: Unauthorized. Use HTTP basic access authentication to access projects that require authentication. Most HTTP client libraries support basic authentication. Please consult the documentation of the library that you use. The Web API uses HTTP realm "TICS".

Whichever client (library) you are using, please make sure that the credentials are supplied regardless of whether the server sends an "authentication challenge". When using wget for instance, it is important to specify the --auth-no-challenge flag, as follows:

wget URL --user USERNAME --password PASSWORD --auth-no-challenge

How To

How to get a list of all projects or a list of all branches for a project?

To get a list of all projects, use the Measure API with metric none and group by Project:

 

The response is formatted like any other Measure API call. The data field of the response is not of interest, as we specified the none metric. However, the nodes field contains an array of path objects, one for each project that you have configured:

{
  "data": [{
      "formattedValue": null,
      "letter": null,
      "value": null,
      "total": 0,
      "success": 0
  }, ...],
  "dates": [
    "2014-04-17T10:40:33.541+02:00"
  ],
  "metrics": [{
      "expression": "none",
      "fullName": "-"
    }
  ],
  "nodes": [{
      "name": "MYPROJECT1",
      "fullPath": "HIE://MYPROJECT1"
    },
    {
      "name": "MYPROJECT2",
      "fullPath": "HIE://MYPROJECT2"
    },
    ...
  ]
}

The fullPath field can be used as input parameter for any follow-up Measure API calls. For example, to get a list of branches for project :

 

How to get a list of all runs for a project?

To get a list of timestamps of moments when an analysis was performed, use the Measure API with metric runs on the project node HIE://, as follows:

 

The response is formatted like any other Measure API call. The data field contains each of the runs. The response looks as follows:

{
  "data": [
    {
      "formattedValue": "-",
      "letter": null,
      "messages": [],
      "status": "PRESENT",
      "value": [
        {
          "started": "2016-09-12T12:02:59.000+02:00"
        },
        {
          "started": "2016-10-04T15:46:58.000+02:00"
        },
        ...
      ]
    }
  ],
  "dates": [
    "2016-10-04T15:48:18.000+02:00"
  ],
  "metrics": [
    {
      "expression": "Runs",
      "fullName": "runs"
    }
  ],
  "nodes": [{
      "name": "MYPROJECT1",
      "fullPath": "HIE://MYPROJECT1"
    },
    {
      "name": "MYPROJECT2",
      "fullPath": "HIE://MYPROJECT2"
    },
    ...
  ]
}

Each of the objects in the list under "value" has a field "started" that indicates when an analysis was started.

Appendix: Python Example Scripts

This section contains some reference scripts that can be used to interact with the TICS APIs. These scripts require the Requests library to run.

Measure API example

The following script demonstrates how the API can be used to retrieve the TQI and lines of code metrics for all files in a project.

#!/usr/bin/env python
import sys
try:
  import requests
except ImportError:
  print('Please install the requests library')
  sys.exit(1)

# Authentication to use for TICS Viewer
username = 'username'
password = 'mypassword'
auth = requests.auth.HTTPBasicAuth(username, password)

# Specify where the TICS Viewer is located
base_url_parameters = dict(
  host='http://',
  section='',
)
base_url = '{host}/tiobeweb/{section}/api/public/v1/'.format(**base_url_parameters)

# Specify input parameters
input_params = dict(
  filters='Project(),File()',
  metrics='tqi,loc',
)

# Query TICS API
r = requests.get(base_url + 'Measure', auth=auth, params=input_params)
if not r.ok:
  print('An error occurred while querying the TICS API')
  print(r.text)
  sys.exit(1)

# Use the response body
response_body = r.json()
idx = 0
for metric in response_body['metrics']:
  for date in response_body['dates']:
    for node in response_body['nodes']:
      metric_value = response_body['data'][idx]
      print('Value for metric {metric}, node {node} at {date} is {formatted_value}'.format(metric=metric['fullName'], node=node['fullPath'], date=date, formatted_value=metric_value['formattedValue']))
      idx += 1

Annotations API example

The following script demonstrates how the API can be used to retrieve a list of level 1 coding standard violations.

#!/usr/bin/env python
import sys
try:
  import requests
except ImportError:
  print('Please install the requests library')
  sys.exit(1)

# Authentication to use for TICS Viewer
username = 'username'
password = 'mypassword'
auth = requests.auth.HTTPBasicAuth(username, password)

# Specify where the TICS Viewer is located
base_url_parameters = dict(
  host='http://',
  section='',
)
base_url = '{host}/tiobeweb/{section}/api/public/v1/'.format(**base_url_parameters)

# Specify input parameters
input_params = dict(
  filters='Project()',
  metric='Annotations(CS)',
)

# Query TICS API
r = requests.get(base_url + 'Annotations', auth=auth, params=input_params)
if not r.ok:
  print('An error occurred while querying the TICS API')
  print(r.text)
  sys.exit(1)

# Use the response body
response_body = r.json()
title = r.json()['header']['title']
print(title)
violations = r.json()['data']
for violation in violations:
  if not violation['supp']: # if not suppressed
    print('{fullPath}:{line} (Category: {category}, Level: {level}) {msg}'.format(**violation))

Appendix: Metrics

A list of commonly used metric expressions is found below. Expressions for metrics that are not listed here can be found by opening a page such as Dashboard or Explorer and selecting the desired metrics. You will find the expressions for the selected metrics in the browser's address bar behind the query parameter named metrics or x (depending on the page).

Expression Description
loc Lines of code
eloc Effective lines of Code
gloc Lines of code including generate code
cycloxAverage Average cyclomatic complexity
cycloxMax Maximum cyclomatic complexity
cycloxTotal Total cyclomatic complexity
fanOut Average fan out
nrOfFunctions Number of functions
deadCode Dead Code (percentage)
duplicatedCode Code Duplication (percentage)
tqi TIOBE Quality Indicator
tqiTestCoverage TQI Code Coverage
tqiAbstrInt TQI Abstract Interpretation
tqiComplexity TQI Cyclomatic Complexity
tqiCompWarn TQI Compiler Warnings
tqiCodingStd TQI Coding Standards
tqiDupCode TQI Code Duplication
tqiFanOut TQI Fan Out
tqiDeadCode TQI Dead Code
linesAdded, linesDeleted, linesChanged Sum of lines added, deleted, or changed in this run
changerate Change rate (total of lines added, deleted, and changed)
accuChangerate Accumulative change rate over all runs
runs List of runs, i.e., timestamps of moments when an analysis was performed
scope+TestCoverage+type
where scope is one of unit, system, integration, or total
and type is one of Branches, Statements, Functions, or Decisions
Unit, System, Integration, or Total Code coverage for Branches, Statements, Functions, or Decisions (16 possible combinations)
Violations(+type+) where type is one of CS,CW,AI, SEC

Total number of coding standard violations, compiler warnings, abstract interpretation violations, or security violations

Deprecated pre-7.4 syntax: violations::type=CODINGSTANDARD, violations::type=COMPILERWARNING, violations::type=ABSTRACTINTERPRETATION

G(Violations(CS),PerKloc())

Number of coding standard violations per 1000 lines of code

Deprecated pre-7.4 syntax: vkloc::type=CODINGSTANDARD

Compliance(CS)

Compliance with respect to coding standard violations (percentage)

Deprecated pre-7.4 syntax: confidence::type=CODINGSTANDARD

Delta(+metric+) where metric is one of the other metrics in this table
The difference between the current value for a metric and the value at the time of the previous baseline. If no baseline is set, the value from a month ago is used instead.
Delta(+metric+,+date+) where metric is one of the other metrics in this table and date is the date to compare to
The difference between the current value for a metric and the value at the date specified. A date may be specified as dd-MM-yyyy, yyyy-MM-dd, ISO 8601 or Unix time.

Appendix: JSONP

When you try to access the WebAPI using JavaScript that is running in your browser, you will run into the browser's same-origin policy. This security policy prevents your script from accessing data on the TICS Viewer, because it is located on a different origin (the combination of hostname, port number, and URI scheme). To overcome this issue, the WebAPI supports JSONP. Another way to overcome the same-origin policy is Cross-origin resource sharing (CORS), but this is not yet supported by the TICS Viewer.

To use JSONP, you have to change the WebAPI URL to include a query parameter named callback, whose value is the name of a JavaScript function that is defined in your script. Instead of the normal JSON payload, the response will be a JavaScript function call to the specified function using the JSON payload as the function's argument. Libraries such as jQuery and Angular support the JSONP convention. Please refer to their respective documentation pages.

Appendix: Languages

When referring to a programming language in the API or in the TICS configuration, you should refer to the languages identifier. Below is a list of supported programming languages and their identifiers.

Programming Language Identifier
C C
C++ CPP
C# CS
Go GO
Java JAVA
JavaScript JAVASCRIPT
Objective-C OBJECTIVEC
PL/SQL SQL
Python PYTHON
Scala SCALA
Swift SWIFT
TypeScript TYPESCRIPT
VB.NET VB
XAML (WPF) XAML