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 programming language.
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 Measure API URL:
The URL has the following variables:
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", "status": "PRESENT" } ], "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.
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 four public endpoints available:
Use the Measure API to obtain (aggregated) metric values one ore more projects, folders, or files, at a specific date.
For example, to get the last measured value for the TIOBE Quality Indicator metric for project
use the following URL:
The input query parameters are:
Parameter | Value | Description |
---|---|---|
metrics
(required) |
metric expression |
A list of metrics for which you want to obtain data. For example, use 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
(optional) |
filter expression |
The filters to apply when retrieving data.
For example, use 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 (or paths)
(optional) |
path expression |
Deprecated
Please use the more powerful
filters parameter instead.
Although this parameter is deprecated, it will remain supported for backwards compatibility.
Please refer to the path expression
When you provide a path that does not exist, the output |
dates
(optional) |
date expression |
Deprecated
Please use the Date
or Run 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. |
wait
(optional) |
true or false
(default=true) |
Whether the API should await cache generation for any project in the queried scope. |
callback
(optional) |
function name |
Use when you want to call the API using the JSONP technique. |
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:
|
||||||||||
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:
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: |
||||||||||
data | An array containing the requested metric value objects. These objects have the following fields:
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.
|
Use the Annotations API to retrieve annotation information for a particular metric and project. In contrast to the Measure API which is used to retrieve aggregated numerical metric data, the Annotations API gives information about the precise locations of issues or other source code facts, as is made available to the user through the Annotated Source view.
For instance, the following URL returns a JSON object containing all Coding Standard violations of level 1 for project :
GET
The input parameters of the Annotations API are:
Parameter | Value | Description | ||||||||
---|---|---|---|---|---|---|---|---|---|---|
metric
(required) |
One of
Annotations(CS) ,
Annotations(CW) ,
Annotations(AI) ,
Annotations(SEC) ,
Annotations(DUP) ,
Annotations(COMPLEXITY) ,
Annotations(DEADCODE) ,
Annotations(DUPCUST)
|
Specifies whether to retrieve annotations for Coding Standards (
Since version 2020.1, you can also retrieve information about
Code Duplication ( |
||||||||
filters
(required) |
filter expression |
Specifies the filters that should be applied. All filters are optional except for the Project filter. The following filters are supported:
In general, the order in which you specify the filters is not important, however there are some exceptions:
the
When requesting annotations for code duplication, the optional filter
In case of the last two types, the scope is determined by the filter that precede the DupScope filter.
For instance, to get all duplications inside |
||||||||
wait
(optional) |
true or false
(default=true) |
Whether the API should await cache generation for any project in the queried scope. |
||||||||
callback
(optional) |
function name |
Use when you want to call the API using the JSONP technique. |
The JSON output fields are:
Field | Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
header |
A JSON object containing meta-data about the response. Currently, it only contains
a
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
data |
An array of Annotation objects that pass the given filters, in no particular order. The returned fields depend on the type of annotations requested. Each object contains the following common fields:
When requesting violation-based annotations, each object additionally contains the following fields:
When requesting code duplication annotations, each object contains the following fields in addition to the common ones:
When requesting complexity annotations, each object reports the complexity of one function found in the source code:
When requesting dead code annotations, each object contains the following fields in addition to the common ones:
|
To get all coding standard violations for a project for category 'Basic', you would do the following request:
GET
To get all complexity annotations for a project for language C++, you would do the following request:
GET
Note that summing the complexity of all returned annotations does not equal the Total Cyclomatic Complexity of the whole project. However, summing the decision counts (complexity-1) does equal the total decision count of whole project.
To get all code duplication annotations for a project you would do the following request:
GET
To get all code duplication annotations that are local within a file, you would do the following request:
GET
To get all code duplication annotations that are external with respect to subsystems 'foo' and 'bar', you would do the following request:
GET
Use the Quality Gate API to query the status of the quality gate(s) that are defined for a particular project (and branch).
Quality Gates are configured in the Administration Pages.
For instance, to get the quality gate status for project
and branch
for the latest run, you would use the following URL:
GET
The input parameters of the QualityGateStatus API are:
Parameter | Value | Description |
---|---|---|
project
(required) |
text | The name of the project you want to get the status for. |
branch
(optional) |
text | The name of the branch inside the project that you want to get the status for. If omitted, the default branch for the project is chosen. |
date
(optional) |
date expression | The date for which you want to get the quality gate status. If omitted, the status for the latest run is returned. |
fields
(optional) |
array of strings |
Since version 2022.1
Comma-separated lists of field names that should be returned in the output.
The purpose of this field is to prevent over-fetching:
you should only specify the fields that are you are going to use.
Valid options are: |
The JSON output fields are:
Field | Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
passed |
Boolean value indicating whether this project (and branch) passes all quality gates configured for it. If no quality gates are configured for the project (or all are disabled), field will be 'true'. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
url |
URL that opens the TiCS Viewer and shows the results of the quality gate status.
The URL is relative to the viewer's base URL, which is of the form |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
message |
String that states the overall quality gate status, for example: |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
gates |
An array of Quality Gate objects. Array does not contain elements for disabled quality gates. Each Quality Gate object contains the following fields:
Each Condition object contains the following fields:
A Details object contains (actionable) details about the problem(s) that make the condition fail. The details are returned in a format that allows the API to be extended later to return extra data, without breaking clients. The object has the following fields:
A DataKey object contains more information about the keys that appear in the
An Item object contains information about one actionable item:
|
An ItemData object containing information about the relevant metric value(s) in the quality gate condition evaluation:
Name | Type | Value |
---|---|---|
value | string |
Numerical metric value. Example: 12.34 .
|
formattedValue | string |
Formatted metric value. Examples: +5 , 12.34% .
|
classes | array of strings |
Classes that characterize this value. Possible values:
|
An array of objects containing a field url
that points to the Annotations API
that you can use to retrieve the particular annotations that are relevant for the failing conditions in the quality gates.
A failing condition will result in a URL in the array if the request will produce a useful result.
For instance, if the quality gate condition is relative, i.e. makes use of a delta metric,
a URL will only be output when annotations support history.
Currently, if no quality gates are defined for the project, the array will contain a URL for each (enabled) violation-based metric, and with filters that ensure that only violations that are new with respect to the previous run are returned. This might change in the future.
To get the quality gate result for project MYPROJECT
including the details for the failing conditions,
query: GET api/public/v1/QualityGateStatus?project=MYPROJECT&fields=details
.
Click here to show the example output.
{ "passed": false, "message": "Project failed to pass quality gate", "url": "api/public/v1/QualityGateStatusDetails?axes\u003dProject(MYPROJECT),Date(1473230970)", "gates": [ { "passed": false, "name": "Blocking coding Standard violations should not increase", "conditions": [ { "passed": false, "error": false, "message": "Δ Coding Standard Violations for levels 1, 2, 3 should be at most 0 for each file with respect to 2016-09-02, but was not for 2 files", "details": { "itemTypes": [ "file" ], "dataKeys": { "actualValue": { "title": "Coding Standard Violations", "order": 1, "itemType": "file" } }, "itemCount": 2, "itemLimit": 100, "items": [ { "itemType": "file", "name": "path/to/File1.c", "link": "AnnotatedSource.html#...", "data": { "actualValue": { "formattedValue": "+10", "value": 10.0, "classes": [ "delta-worse" ] } } }, { "itemType": "file", "name": "other/path/to/File2.c", "link": "AnnotatedSource.html#...", "data": { "actualValue": { "formattedValue": "+1", "value": 1.0, "classes": [ "delta-worse" ] } } } ] } } ] } ] }
To get the quality gate result for project MYPROJECT
,
including links in the output to the Annotations API which allow you to query for detailed annotations,
use query GET api/public/v1/QualityGateStatus?project=MYPROJECT&fields=annotationsApiV1Links
.
Click here to show the example output.
{ "passed": false, "message": "Project failed to pass quality gate", "url": "api/public/v1/QualityGateStatusDetails?axes=Project(MYPROJECT),Date(1473230970)", "gates": [ { "passed": false, "name": "CW absolute", "conditions": [ { "passed": false, "error": false, "message": "Δ Compiler Warnings for levels 1, 2, 3 should be at most 0 for each file with respect to Last month, but was not for 14 files", "annotationsApiV1Links": [ { "url": "api/public/v1/Annotations?filters=Date(1473230970),Project(MYPROJECT),Level(Set(1,2,3)),Where(Eq(Violations(CW),gt,0)),DeltaDate(default),IsNew(yes)&metric=Annotations(CW)" } ] } ] } ], "annotationsApiV1Links": [ { "url": "api/public/v1/Annotations?filters=Date(1473230970),Project(MYPROJECT),Level(Set(1,2,3)),Where(Eq(Violations(CW),gt,0)),DeltaDate(default),IsNew(yes)&metric=Annotations(CW)" } ] }
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).
There is a known issue with the third-party
wkHtmlToImage tool that is used to generate the image,
where the zoom functionality is not working on Ubuntu 20.04.
If you are encountering this issue, you can specify the zoom query parameter as part of the base64-encoded url parameter instead
(available in version 2022.2.1 and higher).
|
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
In this section we describe into more detail the different types of expressions that are used for the input parameters.
A metric expression is used to specify which metric you want to retrieve data for.
Typically, a metric expression consists of a single metric identifier, using the lower camel case naming convention.
For example, you can use tqi
to retrieve the TQI score or tqiCodingStd
for the TQI Coding Standard score.
Other metrics take one or more arguments.
These metrics use the upper camel case convention.
For instance, Violations(argument)
is used to retrieve the number of violations,
where the argument can be any of CS
, CW
, AI
, SEC
to retrieve the number of violations for
coding standards, compiler warnings, abstract interpretation or security respectively.
Other metrics take another metric as argument.
The Delta and 'per KLOC' metrics are examples of this.
For instance, to get the Number of Coding Standard Violations per KLOC, you would use the metric expression PerKloc(Violations(CS))
.
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 the TQI Dashboard
or Explorer
and selecting the desired metrics in the metric picker.
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 |
nrOfDecisionPoints |
The decision count (complexity - 1) |
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 |
tqiSecurity |
TQI Security. Available for projects using TQI version 4.0 or higher. |
tqiDeadCode |
TQI Dead Code. Available only for projects using TQI version 3.11 and lower. |
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 +typewhere scope is one of
and type is one of unit , system , integration , or total 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 |
PerKloc(Violations(CS)) |
Number of coding standard violations per 1000 lines of code |
Log(loc,2) |
The logarithm (base 2) of the Lines of Code metric. |
Compliance(CS) |
Compliance with respect to coding standard violations (percentage) |
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. The date should be specified as a date expression. |
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
FilterName(parameter)
.
The filter 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 filter on a set of values, containing at least two elements.
The are specified using a filter expression of the form FilterName(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 FilterName()
.
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 all API end points described here. The viewer uses additional 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.
,
, (
, 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
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
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 |
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(…)
Ruleset(…)
|
Confines violation metrics to a specific coding rule level, category, name, or ruleset. 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(date expression) |
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. For example, to get the value for Lines of Code at January 2, 2019, use: |
CodeType(…)
Since version 9.1
|
Confines metric values to the given code types.
A code type of a file is either Information about configuring code types is found here |
Run()
Run(Period(begin date))
Since version 2019.4
|
The runs for which to obtain data.
When using this filter, you should not use the
Use To get the Lines of Code measurements for a sliding window of the last three months use: |
Date expressions are used inside the Date()
and Run()
filters,
and as the second parameter in the Delta
metric.
The following date expressions are supported:
Expression | Description |
---|---|
date literal |
A date literal of one of the following types:
|
Run(index) |
Resolves to the date associated with the run (analysis) found at the given index in the complete list of runs sorted in ascending order for all projects in the current scope. A negative index can be used to access the list in descending order, which is useful to get to the most recent runs. Most useful expressions are:
When you combine a Run date expression (with negative index) with a |
RunChange(index) |
Similar to
|
Baseline(name)
|
Resolves to the date associated with the baseline with the given name in the current scope is defined. |
default
|
Resolves to the default reference date, which is the date associated with the last baseline in the current scope, or the last month if no baseline defined in the current scope. |
Add(date expression,duration)
|
Computes a date by adding given duration to the date pointed to by given date expression.
Durations should be in ISO Duration format.
For instance, Add(Run(-1),P-7D) would resolve to 7 days before the last analysis.
|
duration
|
You can also directly specify a duration in ISO Duration format
at all places where a date expression is expected.
The duration will be interpreted relatively to the last analysis date (Run(-1) ).
For instance, Delta(loc,P-7D) is a shorthand for writing Delta(loc,Add(Run(-1),P-7D)) .
|
A path expression denotes a single project, branch, folder or file and is a combination of a hierarchy specifier (HIE or ORG), followed by a comma-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, Path(HIE,MYPROJECT,trunk,path,to,file.cpp)
denotes file named 'file.cpp' in folder 'path/to' in branch 'trunk', project 'MYPROJECT'.
Path(HIE,MYPROJECT,trunk)
denotes the root folder in the branch.
Path(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.
filters
parameter instead (when available).
A path literal is an instance of a path expression that uses a different and deprecated syntax:
HIE://MYPROJECT/trunk/path/to/file.cpp
.
This syntax has as limitation that branches with a forward slash in the name cannot be expressed,
because the part after the /
will be interpreted as a folder.
Therefore, you should not use path literals as input, use the expression syntax instead.
Unfortunately, the APIs do still output the ambiguous path literals, for backwards compatibility.
In this section we discuss general API aspects, such as authentication.
The Web API respects any authentication that you might have configured in your SERVER.yaml. 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
After TICS finishes analysis of a project, it sends a notification to the viewer. The viewer needs time to generate caches for the new data. Depending on the size of the project and the server hardware, this might take a while, even up to an hour for very large projects. The Measure and Annotations API by default wait while cache generation for a project is active before returning results. This ensures that if you do an API call right after a TiCS analysis has finished, you will get the latest results, rather than the previous data.
Alternatively, you can use the query parameter wait=false
to tell the API not to wait for cache generation to complete.
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.
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 :
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.
This section contains some reference scripts that can be used to interact with the TICS APIs. These scripts require the Requests library to run.
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
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))
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 |
Dart | DART |
Go | GO |
Java | JAVA |
JavaScript | JAVASCRIPT |
Kotlin | KOTLIN |
Lua | LUA |
Matlab | MATLAB |
Objective-C | OBJECTIVEC |
PL/SQL | SQL |
Python | PYTHON |
Scala | SCALA |
Swift | SWIFT |
TypeScript | TYPESCRIPT |
Visual Basic .NET | VB |
XAML (WPF) | XAML |