Implement GET all resources APIs with filter parameter

Introduction

Filtering is a great way for SCIM clients to request a subset of resources by specifying the “filter” query parameter containing a filter expression. When specified, only those resources matching the filter expression will be returned. The expression language that is used with the filter parameter supports references to attributes and literals.

Operator supported in the expression of filter

Attribute names and attribute operators used in filters are case insensitive. For example, the following two expressions will evaluate to the same logical value:
filter=claimType eq “urn:test:com”
filter=ClaimType EQ “urn:test:com”

Attribute Operators

Operator Description Behavior
eq equal The attribute and operator values must be identical for a match.
ne not equal The attribute and operator values are not identical.
co contains The entire operator value must be a substring of the attribute value for a match.
sw starts with The entire operator value must be a substring of the attribute value, starting at the beginning of the attribute value. This criterion is satisfied if the two strings are identical.
ew ends with The entire operator value must be a substring of the attribute value, matching at the end of the attribute value. This criterion is satisfied if the two strings are identical.
pr present (has value) If the attribute has a non-empty or non-null value, or if it contains a non-empty node for complex attributes, there is a match.
gt greater than If the attribute value is greater than the operator value, there is a match. The actual comparison is dependent on the attribute type. For string attribute types, this is a lexicographical comparison, and for DateTime types, it is a chronological comparison. For integer attributes, it is a comparison by numeric value. Boolean and Binary attributes will cause a failed response (HTTP status code 400) with “scimType” of “invalidFilter”.
ge greater than or equal to If the attribute value is greater than or equal to the operator value, there is a match. The actual comparison is dependent on the attribute type. For string attribute types, this is a lexicographical comparison, and for DateTime types, it is a chronological comparison. For integer attributes, it is a comparison by numeric value. Boolean and Binary attributes will cause a failed response (HTTP status code 400) with “scimType” of “invalidFilter”.
lt less than If the attribute value is less than the operator value, there is a match. The actual comparison is dependent on the attribute type. For string attribute types, this is a lexicographical comparison, and for DateTime types, it is a chronological comparison. For integer attributes, it is a comparison by numeric value. Boolean and Binary attributes will cause a failed response (HTTP status code 400) with “scimType” of “invalidFilter”.
le less than or equal to If the attribute value is less than or equal to the operator value, there is a match. The actual comparison is dependent on the attribute type. For string attribute types, this is a lexicographical comparison, and for DateTime types, it is a chronological comparison. For integer attributes, it is a comparison by numeric value. Boolean and Binary attributes will cause a failed response (HTTP status code 400) with “scimType” of “invalidFilter”.

Logical Operators

Operator Description Behavior
and Logical “and” The filter is only a match if both expressions evaluate to true.
or Logical “or” The filter is a match if either expressions evaluate to true.
not “Not” function The filter is a match if expressions evaluate to false.

Grouping Operators

Operator Description Behavior
( ) Precedence grouping Boolean expressions are grouped using parentheses to change the standard order of operations, i.e., to evaluate logical “or” operators before logical “and” operators.
[ ] Complex attribute filter grouping Identify supports complex filters where expressions are applied to the same value of a parent attribute specified immediately before the left square bracket (“[“). The expression within square brackets (“[” and “]”) is a valid filter expression based upon sub-attributes of the parent attribute. Nested expressions is supported as well.
Was this helpful ?Good Somewhat Bad