Options to limit size of the individual response

Starting from 10.0.2, BigFix Inventory uses HTTP streaming in JSON responses. In HTTP response method, the HTTP Header Transfer Encoding is set to chunked and the response size is not determined. As a result, the data is available in stream as the database provides records that matches the API. With this improvement, pagination in the API is optional and all data can be fetched with a single query.

Using limit and offset

The limit and offset parameters works as same as their representation in SQL/RDBMS. This allows to page over the result set. The first page, Tradeoff is available in the shortest time and other subsequent pages load slowly. It needs more data to load the subsequent pages and it cannot be optimized.

When you retrieve data in bulk, you can also make several API requests and use the limit and offset parameters to paginate your results instead of retrieving all the data at the same time:

Use the limit parameter to specify the number of retrieved results:

https://hostname:port/URL?token=token&countSwitch=1&limit=10000&offset=0

For example:

https://192.0.2.2:9081/api/sam/v2/computers?token=token&countSwitch=1&limit=10000&offset=0

If you limit the first request to 100000 results, append the next request with the offset=100000 parameter to omit the records that you already retrieved:
```
https://hostname:port/URL?token=token&countSwitch=1&limit=10000&offset=10000
```
For example:
```
https://192.0.2.2:9081/api/sam/v2/computers?token=token&countSwitch=1&limit=10000&offset=10000
```

Note: The limit and offset parameters can be omitted if you are retrieving data for 50 endpoints. For environments with approximately 200000 endpoints, you are advised to retrieve data in pages of 100000 rows for computer systems, 200000 rows for software instances, and 300000 rows for license usage.

Using criteria

The alternative method depends on the API instance and is based on using criteria. It allows to optimize response time for subsequent pages as the application can extract information directly about the page, without preparing the whole data.

Limit and offset parameters require to have the results ready according to some order and then extract it partially. With this approach, the API, when requested, yields the entire result. The pages are reported at different time. However, size of response varies due to the data structure.

Software Instance Paging example using criteria

There instance_id field provides an unique value of the entry. It does not guarantee that there will be no gaps in instance_id number. First instance_id is 1.

To get maximum value of instance_id, use the below example:

https://hostname:port/api/sam/v2/software_instances?columns[]=instance_id&order[]=instance_id%20desc&offset=0&limit=1&countSwitch=1

The return value is:

{"total":-1,"rows":[{"instance_id":162}]}

Specifying order (order[]=instance_id desc) assures that as first will be reported with maximum value, so we can get just top row (limit=1). Returned value is maximum value of instance_id.

You can page over the software_instances using instance_id and criteria.

Below is an example request:https://hostname:port/api/sam/v2/software_instances?columns[]=computer_id&columns[]=instance_id&columns[]=component_name&offset=0&limit=10000&countSwitch=1&criteria={"and":[["instance_id",">=","1"],["instance_id ","<","10000"]]}

Limit and offset values are additional parameters but it is recommended to use them.

Control over paging is moved to the criteria part then:

criteria={"and":[

["instance_id",">=","1"],

["instance_id ","<","10000"]

]}

Next page is returned by passing:

criteria={"and":[

["instance_id",">=","10000"],

["instance_id ","<","20000"]

]}

This method leverage data indexes to extract immediately desired subset of data and should provide more stable response times over subsequent queries.