Filtering and Sorting Expressions in the Main API

filtering and sorting expressions this example describes the player entity, but the same solution is implemented for all other entities (for example, groups, feeds, playlists, etc ) example the bsn cloud main api currently exposes the following player management methods which accept optional filter and sort expressions which retrieves the paged list including up to 100 'device' instances starting from the specified marker, matching the specified filter expression and sorted in accordance to the specified sort expression which retrieves the list of 'devicesregion' providing the aggregated information of locations of 'device' instances matching the specified location path and filter expression which retrieves the number of 'device' instances matching the specified filter expression (in development) which applies the specified changes to 'device' instances matching the specified filter expression which deletes the 'device' instances matching the specified filter expression filter expression criteria each filter expression may contain one or more criteria combined by and/or operators and optionally grouped by parentheses each criteria may be based on property name, system tag, or custom tag all property names are based on data contract of the target main api version system and custom tags in addition to properties each 'player' entity instance may have a different set of system and custom tags specified by customer, exposed via the \[dictionary\<string, object>] tags property and managed via the following bsn cloud main api methods each system and custom tag must be explicitly specified for the target entity instance but the list of available system tags is predefined by product owners and mapped to some properties so their values must be always in sync for example, the system tag mapped to the player health status property is called string \[device] \<healthstatus> property and tag mentions in expressions property and tag mentions in expressions are different properties are wrapped by square brackets and are separated by dots while tags are wrapped by angle brackets and may optionally be prepended by the target entity name in square brackets, and the data type is separated by double colon as you can see in the example above each property and tag has a strong data type, for properties and system tags it is defined in data contract of a target api version and for custom tags it is resolved either from fully qualified name or first assigned value in addition, there is a request to support custom tags without values acting as labels the data type defines which operators and functions are applicable to a given property or tag in conditions the properties and tags of boolean data type typically support the following operators the properties and tags of numeric data types typically support the following operators the gps coordinates also support expressions like the properties and tags of string data type typically support the following operators the expressions used in is and is not operators may include ' ', '?', '\[' + ']' wildcards the properties and tags of datetime (timestamp) data type typically support the following operators where {interval} is one of { "years", "months", "days" } enumeration values where {interval} is one of { "years", "months", "days" } enumeration values the '{datetime}' value format must follow iso 8601 and is typically like '2021 12 20t18 25 01 123z' the properties and tags of timespan (time interval) data type typically support the following operators the '{timespan}' value format must follow iso 8601 and is typically like '3 18 25 01' the properties and tags of numeric array data types typically support the following operators the properties and tags of string array data type typically support the following operators the properties and tags of object data type typically support the following operators sort expressions may contain only one fully qualified property name or tag with optional asc/desc qualifier, but should support more in future