0N/A<?
xml version="1.0" encoding="UTF-8"?>
0N/A ! This work is licensed under the Creative Commons 0N/A ! Attribution-NonCommercial-NoDerivs 3.0 Unported License. 0N/A ! To view a copy of this license, visit 0N/A ! or send a letter to Creative Commons, 444 Castro Street, 0N/A ! Suite 900, Mountain View, California, 94041, USA. 0N/A ! You can also obtain a copy of the license at 0N/A ! See the License for the specific language governing permissions 0N/A ! and limitations under the License. 0N/A ! If applicable, add the following below this CCPL HEADER, with the fields 0N/A ! enclosed by brackets "[]" replaced with your own identifying information: 873N/A ! Portions Copyright [yyyy] [name of copyright owner] 0N/A ! Copyright 2013 ForgeRock AS 0N/A<
chapter xml:
id='chap-rest-operations' 0N/A <
title>Performing RESTful Operations</
title>
1617N/A <
indexterm><
primary>HTTP</
primary></
indexterm>
0N/A <
indexterm><
primary>JSON</
primary></
indexterm>
0N/A <
indexterm><
primary>REST</
primary></
indexterm>
0N/A <
para>OpenDJ lets you access directory data as JSON resources over HTTP.
0N/A This chapter demonstrates basic RESTful client operations using the
0N/A default configuration and sample directory data imported into OpenDJ from
2086N/A OpenDJ directory server as described in procedure, <
link xlink:
show="new" 2086N/A xlink:
href="admin-guide#setup-rest2ldap-connection-handler" 1280N/A Access to OpenDJ Directory Server</
citetitle></
link>.</
para>
2086N/A <
para>Interface stability: <
link xlink:
href="admin-guide#interface-stability" 0N/A >Evolving</
link></
para>
0N/A <
section xml:
id="understand-rest">
0N/A <
title>Understanding the OpenDJ REST API</
title>
0N/A <
para>The OpenDJ REST API is built on a common ForgeRock HTTP-based REST API
0N/A for interacting with JSON Resources. APIs built on this common layer all let
0N/A you perform the following operations.</
para>
0N/A <
term><
link linkend="create-rest">Create</
link></
term>
0N/A <
para>Add a resource that does not yet exist</
para>
0N/A <
term><
link linkend="read-rest">Read</
link></
term>
1617N/A <
para>Retrieve a single resource</
para>
0N/A <
term><
link linkend="update-rest">Update</
link></
term>
0N/A <
para>Replace an existing resource</
para>
0N/A <
term><
link linkend="delete-rest">Delete</
link></
term>
0N/A <
para>Remove an existing resource</
para>
0N/A <
term><
link linkend="patch-rest">Patch</
link></
term>
0N/A <
para>Modify part of an existing resource</
para>
0N/A <
term><
link linkend="action-rest">Action</
link></
term>
0N/A <
para>Perform a predefined action</
para>
0N/A <
term><
link linkend="query-rest">Query</
link></
term>
0N/A <
para>List a set of resources</
para>
0N/A <
para>The present implementation in OpenDJ maps JSON resources onto LDAP
0N/A entries, meaning REST clients can in principle do just about anything an
0N/A LDAP client can do with directory data.</
para>
1617N/A <
para>In addition to query string parameters that depend on the operation,
0N/A the examples in this chapter make use of the following parameters that
1617N/A apply to the JSON resource returned for all operations.</
para>
0N/A <
term><
literal>_fields=<
replaceable>field</
replaceable>[,…]</
literal></
term>
0N/A <
para>Retain only the specified fields in the JSON resource returned.</
para>
2086N/A <
term><
literal>_prettyPrint=true|false</
literal></
term>
0N/A <
para>Make the JSON resource returned easy for humans to read.</
para>
2086N/A <
section xml:
id="authenticate-rest">
0N/A <
title>Authenticating Over REST</
title>
0N/A <
para>When you first try to get a resource that you can read as an LDAP
0N/A entry with an anonymous search, you might be surprised that you must
0N/A authenticate.</
para>
0N/A "reason" : "Unauthorized",
0N/A "message" : "Unauthorized"
0N/A <
para>HTTP status code 401 tells your HTTP client that the request requires
0N/A user authentication. You can change this behavior by setting the HTTP
0N/A connection handler property, <
literal>authentication-required</
literal>,
0N/A to <
literal>false</
literal>.</
para>
0N/A set-connection-handler-prop
0N/A --bindDN "cn=Directory Manager"
0N/A --bindPassword password
0N/A --handler-name "HTTP Connection Handler"
0N/A --set authentication-required:false
0N/A <
para>Out of the box both the HTTP Connection Handler and also the REST LDAP
0N/A gateway are configured to allow HTTP Basic authentication and HTTP header
0N/A based authentication in the style of OpenIDM. The authentication mechanisms
0N/A translate HTTP authentication to LDAP authentication on the directory server
0N/A <
para>When you install OpenDJ either with generated sample user entries or
0N/A attribute for the sample user entries is the user ID (<
literal>uid</
literal>)
0N/A attribute. For example, the DN and user ID for Babs Jensen are as
0N/A <
programlisting language="ldif">dn: uid=bjensen,ou=People,dc=example,dc=com
0N/Auid: bjensen</
programlisting>
0N/A <
para>Given this pattern in the user entries, the default REST to LDAP
0N/A configuration assumes that the user name on the HTTP side is the value of
0N/A the user ID, and that user entries can be found under
0N/A <
literal>ou=People,dc=example,dc=com</
literal>. In other words, Babs Jensen
0N/A authenticates as <
literal>bjensen</
literal> (password:
0N/A <
literal>hifalutin</
literal>) over HTTP. This is mapped for an LDAP bind
0N/A to the bind DN <
literal>uid=bjensen,ou=People,dc=example,dc=com</
literal>.</
para>
0N/A <
para>With HTTP Basic authentication, it looks like this.</
para>
0N/A --user bjensen:hifalutin
0N/A "_rev" : "0000000016cbb68c",
0N/A <
para>Or, using the HTTP Basic
0N/A <
replaceable>username</
replaceable>:<
replaceable>password</
replaceable>@ form
0N/A in the URL, it looks like this.</
para>
0N/A "_rev" : "0000000016cbb68c",
0N/A <
para>With HTTP header based authentication, it looks like this.</
para>
0N/A --header "X-OpenIDM-Username: bjensen"
0N/A --header "X-OpenIDM-Password: hifalutin"
0N/A "_rev" : "0000000016cbb68c",
0N/A <
para>If your directory data are laid out differently, or if your user names
0N/A are email addresses rather than user IDs for example, then you must update
0N/A the configuration in order for authentication to work.</
para>
0N/A <
para>The REST LDAP gateway can also translate HTTP user name and password
0N/A authentication to PLAIN SASL authentication on the LDAP side. Moreover, the
0N/A gateway can fall back to proxied authorization as necessary, using a root DN
0N/A authenticated connection to LDAP servers. See <
link xlink:
show="new" 0N/A xlink:
href="admin-guide#appendix-rest2ldap" 0N/A Configuration</
citetitle></
link> for details on all configuration
0N/A <
section xml:
id="create-rest">
0N/A <
title>Creating Resources</
title>
0N/A <
para>There are two ways to create resources.</
para>
0N/A <
para>To create a resource using an ID that you specify, perform an HTTP PUT
0N/A <
literal>If-None-Match: *</
literal>, and the JSON content of your
0N/A <
para>The following example creates a new user entry with ID
0N/A <
literal>newuser</
literal>.</
para>
0N/A --user kvaughan:bribery
0N/A --header "If-None-Match: *"
0N/A "contactInformation": {
0N/A "telephoneNumber": "+1 408 555 1212",
2086N/A "emailAddress": "newuser@example.com"
0N/A "familyName": "New",
0N/A "displayName": "New User",
2086N/A "displayName": "Kirsten Vaughan"
0N/A "_rev" : "000000005b337348",
0N/A "schemas" : [ "urn:scim:schemas:core:1.0" ],
0N/A "contactInformation" : {
0N/A "telephoneNumber" : "+1 408 555 1212",
2086N/A "emailAddress" : "newuser@example.com"
0N/A "familyName" : "New",
0N/A "givenName" : "User"
0N/A "userName" : "newuser@example.com",
0N/A "displayName" : "New User",
0N/A "created" : "2013-04-11T09:58:27Z"
0N/A "displayName" : "Kirsten Vaughan"
0N/A <
para>To create a resource letting the server choose the ID, perform an HTTP
0N/A POST with <
literal>_action=create</
literal> as described in
2086N/A <
xref linkend="action-rest" />.</
para>
0N/A <
section xml:
id="read-rest">
0N/A <
title>Reading a Resource</
title>
0N/A <
para>To read a resource, perform an HTTP GET.</
para>
0N/A --user kvaughan:bribery
2086N/A "_rev" : "000000005b337348",
0N/A "schemas" : [ "urn:scim:schemas:core:1.0" ],
0N/A "contactInformation" : {
0N/A "telephoneNumber" : "+1 408 555 1212",
0N/A "emailAddress" : "newuser@example.com"
0N/A "familyName" : "New",
0N/A "givenName" : "User"
0N/A "userName" : "newuser@example.com",
0N/A "displayName" : "New User",
0N/A "created" : "2013-04-11T09:58:27Z"
0N/A "displayName" : "Kirsten Vaughan"
0N/A <
section xml:
id="update-rest">
0N/A <
title>Updating Resources</
title>
0N/A <
para>To update a resource, perform an HTTP PUT with the changes to the
0N/A resource. For read-only fields, either include unmodified versions, or omit
0N/A them from your updated version.</
para>
0N/A <
para>The following example adds a manager for Sam Carter.</
para>
0N/A --user kvaughan:bribery
2086N/A "telephoneNumber": "+1 408 555 4798",
0N/A "emailAddress": "scarter@example.com"
0N/A "familyName": "Carter",
2086N/A "userName": "scarter@example.com",
2086N/A "displayName": "Sam Carter",
0N/A "_id": "Accounting Managers"
0N/A "displayName": "Torrey Rigden"
0N/A "_rev" : "00000000a1923db2",
2086N/A "schemas" : [ "urn:scim:schemas:core:1.0" ],
2086N/A "telephoneNumber" : "+1 408 555 4798",
0N/A "emailAddress" : "scarter@example.com"
0N/A "familyName" : "Carter",
2086N/A "userName" : "scarter@example.com",
2086N/A "displayName" : "Sam Carter",
0N/A "displayName" : "Torrey Rigden"
0N/A "lastModified" : "2013-04-12T07:42:34Z"
0N/A "_id" : "Accounting Managers"
<
para>To update a resource only if the resource matches a particular version,
use an <
literal>If-Match: <
replaceable>revision</
replaceable></
literal>
<
emphasis>{"_rev":"00000000b017c5b8"}</
emphasis>
<
emphasis>--header "If-Match: 00000000b017c5b8"</
emphasis>
"telephoneNumber": "+1 408 555 1212",
"emailAddress": "scarter@example.com"
"userName": "scarter@example.com",
"displayName": "Sam Carter",
"_id": "Accounting Managers"
"displayName": "Torrey Rigden"
"_rev" : "00000000a1ee3da3",
"schemas" : [ "urn:scim:schemas:core:1.0" ],
"telephoneNumber" : "+1 408 555 1212",
"emailAddress" : "scarter@example.com"
"userName" : "scarter@example.com",
"displayName" : "Sam Carter",
"lastModified" : "2013-04-12T07:47:45Z"
"_id" : "Accounting Managers"
"displayName" : "Torrey Rigden"
<
section xml:
id="delete-rest">
<
title>Deleting Resources</
title>
<
para>To delete a resource, perform an HTTP DELETE on the resource URL.
On success, the operation returns the resource you deleted.</
para>
"_rev" : "000000003a5f3cb2",
"schemas" : [ "urn:scim:schemas:core:1.0" ],
"telephoneNumber" : "+1 408 555 1212",
"emailAddress" : "newuser@example.com"
"userName" : "newuser@example.com",
"displayName" : "New User",
"created" : "2013-04-11T09:58:27Z"
"displayName" : "Kirsten Vaughan"
<
para>To delete a resource only if the resource matches a particular version,
use an <
literal>If-Match: <
replaceable>revision</
replaceable></
literal>
{"_rev":"000000006d8d7358"}
--header "If-Match: 000000006d8d7358"
"_rev" : "00000000383f3cae",
"schemas" : [ "urn:scim:schemas:core:1.0" ],
"telephoneNumber" : "+1 408 555 1212",
"emailAddress" : "newuser@example.com"
"userName" : "newuser@example.com",
"displayName" : "New User",
"created" : "2013-04-11T12:48:48Z"
"displayName" : "Kirsten Vaughan"
<
para>To delete a resource and all its children, you must change the
configuration, get the REST LDAP gateway or HTTP Connection Handler to
reload its configuration, and perform the operation as a user who has the
access rights required. The following steps show one way to do this with
the HTTP Connection Handler.</
para>
<
para>In this case the LDAP view of the user to delete shows two child
<
screen>$ ldapsearch --port 1389 --baseDN uid=nbohr,ou=people,dc=example,dc=com "(&)" dn
dn: uid=nbohr,ou=People,dc=example,dc=com
dn: cn=quantum dot,uid=nbohr,ou=People,dc=example,dc=com
dn: cn=qubit generator,uid=nbohr,ou=People,dc=example,dc=com</
screen>
<
para>In the configuration file for the HTTP Connection Handler, by default
<
literal>"useSubtreeDelete" : true</
literal>.</
para>
<
para>After this change, only users who have access to request a tree
delete can delete resources.</
para>
<
para>Force the HTTP Connection Handler to reread its configuration.</
para>
set-connection-handler-prop
--bindDN "cn=Directory Manager"
--handler-name "HTTP Connection Handler"
<
emphasis>--set enabled:false</
emphasis>
set-connection-handler-prop
--bindDN "cn=Directory Manager"
--handler-name "HTTP Connection Handler"
<
emphasis>--set enabled:true</
emphasis>
<
para>Delete as a user who has rights to perform a subtree delete on
"_rev" : "000000003d912113",
"schemas" : [ "urn:scim:schemas:core:1.0" ],
"telephoneNumber" : "+1 408 555 1212",
"emailAddress" : "nbohr@example.com"
"userName" : "nbohr@example.com",
"displayName" : "Niels Bohr"
<
section xml:
id="patch-rest">
<
title>Patching Resources</
title>
<
para>OpenDJ lets you patch JSON resources, updating part of the resource
rather than replacing it. For example, you could change Babs Jensen's
email address by issuing an HTTP PATCH request, as in the example that
<
para>Notice that the data sent specifies the type of patch operation, the
field to change, and a value that depends on the field you change and on the
operation. A single-valued field takes an object, boolean, string, or number
depending on its type, whereas a multi-valued field takes an array of values.
Getting the type wrong results in an error. Also notice that the patch data is
itself an array, since you could patch more than one part of the resource by
using a set of patch operations in the same request.</
para>
"value": "babs@example.com"
"_rev" : "00000000f3fdd370",
"schemas" : [ "urn:scim:schemas:core:1.0" ],
"telephoneNumber" : "+1 408 555 1862",
"emailAddress" : "babs@example.com"
"userName" : "babs@example.com",
"displayName" : "Barbara Jensen",
"lastModified" : "2013-05-13T14:35:31Z"
"displayName" : "Torrey Rigden"
<
para>OpenDJ supports four types of patch operation.</
para>
<
para>The add operation ensures that the target field contains the value
provided, creating parent fields as necessary.</
para>
<
para>If the target field is single-valued and a value already exists, then
that value is replaced with the value you provide. <
emphasis role="strong">Note that you do not get an error when adding a value to a
single-valued field that already has a value.</
emphasis> A single-valued
field is one whose value is not an array (an object, string, boolean, or
<
para>If the target field is multi-valued, then the array of values you
provide is merged with the set of values already in the resource. New
values are added, and duplicate values are ignored. A multi-valued field
takes an array value.</
para>
<
para>The remove operation ensures that the target field does not contain
the value provided. If you do not provide a value, the entire field is
removed if it already exists.</
para>
<
para>If the target field is single-valued and a value is provided, then
the provided value must match the existing value to remove, otherwise the
field is left unchanged.</
para>
<
para>If the target field is multi-valued, then values in the array you
provide are removed from the existing set of values.</
para>
<
para>The replace operation removes existing values on the target field,
and replaces them with the values you provide. It is equivalent to
performing a remove on the field, then an add with the values you
<
para>The increment operation increments or decrements the value or values
in the target field by the amount you specify, which is positive to
increment, negative to decrement. The target field must be a number or
a set of numbers. The value you provide must be a single number.</
para>
<
para>One key nuance in how patch works with OpenDJ has to do with
multi-valued fields. Although JSON resources represent multi-valued fields as
<
emphasis>arrays</
emphasis>, OpenDJ treats those values as
<
emphasis>sets</
emphasis>. In other words, values in the field are unique,
and the ordering of an array of values is not meaningful in the context of
patch operations. If you reference array values by index, OpenDJ returns
an error.<
footnote><
para>OpenDJ does let you use a hyphen as the last element
of the "field" JSON pointer value to add an element to the set, as in
<
command>curl --user kvaughan:bribery --request PATCH --header "Content-Type:
"value" : { "_id" : "bjensen" } }]'
<
para>Instead use the patch operations as if arrays values were sets. For
example, you can include Barbara Jensen in a group by adding her to the set
"_rev" : "00000000b70c881a",
"schemas" : [ "urn:scim:schemas:core:1.0" ],
"_id" : "Directory Administrators",
"displayName" : "Directory Administrators",
"lastModified" : "2013-05-13T16:40:23Z"
"displayName" : "Kirsten Vaughan"
"displayName" : "Robert Daugherty"
"displayName" : "Barbara Jensen"
"displayName" : "Harry Miller"
<
para>Removing her from the group is similar.</
para>
"_rev" : "00000000e241797e",
"schemas" : [ "urn:scim:schemas:core:1.0" ],
"_id" : "Directory Administrators",
"displayName" : "Directory Administrators",
"lastModified" : "2013-05-13T16:40:55Z"
"displayName" : "Kirsten Vaughan"
"displayName" : "Robert Daugherty"
"displayName" : "Harry Miller"
<
para>You can use resource revision numbers in <
literal>If-Match:
<
replaceable>revision</
replaceable></
literal> headers to patch the resource
only if the resource matches a particular version.</
para>
"_rev" : "00000000c1b6d4c7"
--header "If-Match: 00000000c1b6d4c7"
"value": "babs@example.com"
"_rev" : "00000000f946d377",
"schemas" : [ "urn:scim:schemas:core:1.0" ],
"telephoneNumber" : "+1 408 555 1862",
"emailAddress" : "babs@example.com"
"userName" : "babs@example.com",
"displayName" : "Barbara Jensen",
"lastModified" : "2013-05-13T16:56:33Z"
"displayName" : "Torrey Rigden"
<
para>The resource revision changes after you successfully perform the patch
<
section xml:
id="action-rest">
<
title>Using Actions</
title>
<
para>OpenDJ implements an action that lets the server set the resource ID
on creation. To use this action, perform an HTTP POST with header
<
literal>_action=create</
literal> in the query string, and the JSON content of
<
para>The following example creates a new user entry.</
para>
<
screen width="82">$ curl
"telephoneNumber": "+1 408 555 1212",
"emailAddress": "newuser@example.com"
"displayName": "New User",
"displayName": "Kirsten Vaughan"
"_rev" : "0000000034a23ca7",
"schemas" : [ "urn:scim:schemas:core:1.0" ],
"telephoneNumber" : "+1 408 555 1212",
"emailAddress" : "newuser@example.com"
"userName" : "newuser@example.com",
"displayName" : "New User",
"created" : "2013-04-11T11:19:08Z"
"displayName" : "Kirsten Vaughan"
<
section xml:
id="query-rest">
<
title>Querying Resource Collections</
title>
<
para>To query resource collections, perform an HTTP GET with a
<
literal>_queryFilter=<
replaceable>filter</
replaceable></
literal> parameter
in your query string.</
para>
<
para>For query operations, your <
replaceable>filter</
replaceable>
expressions are constructed from the following building blocks.
Make sure you URL encode the filter expressions, which are shown here
without URL encoding to make them easier to read.</
para>
<
para>In these expressions the simplest
<
replaceable>json-pointer</
replaceable> is a field of the JSON resource,
such as <
literal>userName</
literal> or <
literal>id</
literal>. A
<
replaceable>json-pointer</
replaceable> can however point to nested
elements as described in the <
link xlink:
show="new" Pointer</
link> Internet-Draft.</
para>
<
term>Comparison expressions</
term>
<
para>You can build filters using the following comparison expressions.</
para>
<
term><
literal><
replaceable>json-pointer</
replaceable> eq <
replaceable>json-value</
replaceable></
literal></
term>
<
para>Matches when the pointer equals the value, as in the following
/users?_queryFilter=userName+eq+"bjensen@example.com"&_prettyPrint=true'
"_rev" : "00000000315fb731",
"schemas" : [ "urn:scim:schemas:core:1.0" ],
"displayName" : "Torrey Rigden"
"telephoneNumber" : "+1 408 555 1862",
"emailAddress" : "bjensen@example.com"
"userName" : "bjensen@example.com",
"displayName" : "Barbara Jensen"
"pagedResultsCookie" : null,
"remainingPagedResults" : -1
<
term><
literal><
replaceable>json-pointer</
replaceable> co <
replaceable>json-value</
replaceable></
literal></
term>
<
para>Matches when the pointer contains the value, as in the following
/users?_queryFilter=userName+co+"jensen"&_fields=userName&_prettyPrint=true'
"userName" : "ajensen@example.com"
"userName" : "bjensen@example.com"
"userName" : "gjensen@example.com"
"userName" : "jjensen@example.com"
"userName" : "kjensen@example.com"
"userName" : "rjensen@example.com"
"userName" : "tjensen@example.com"
"pagedResultsCookie" : null,
"remainingPagedResults" : -1
<
term><
literal><
replaceable>json-pointer</
replaceable> sw <
replaceable>json-value</
replaceable></
literal></
term>
<
para>Matches when the pointer starts with the value, as in the
following example.</
para>
/users?_queryFilter=userName+sw+"ab"&_fields=userName&_prettyPrint=true'
"userName" : "abarnes@example.com"
"userName" : "abergin@example.com"
"pagedResultsCookie" : null,
"remainingPagedResults" : -1
<
term><
literal><
replaceable>json-pointer</
replaceable> lt <
replaceable>json-value</
replaceable></
literal></
term>
<
para>Matches when the pointer is less than the value, as in the
following example.</
para>
/users?_queryFilter=userName+lt+"ac"&_fields=userName&_prettyPrint=true'
"userName" : "abarnes@example.com"
"userName" : "abergin@example.com"
"pagedResultsCookie" : null,
"remainingPagedResults" : -1
<
term><
literal><
replaceable>json-pointer</
replaceable> le <
replaceable>json-value</
replaceable></
literal></
term>
<
para>Matches when the pointer is less than or equal to the value, as
in the following example.</
para>
/users?_queryFilter=userName+le+"ad"&_fields=userName&_prettyPrint=true'
"userName" : "abarnes@example.com"
"userName" : "abergin@example.com"
"userName" : "achassin@example.com"
"pagedResultsCookie" : null,
"remainingPagedResults" : -1
<
term><
literal><
replaceable>json-pointer</
replaceable> gt <
replaceable>json-value</
replaceable></
literal></
term>
<
para>Matches when the pointer is greater than the value, as in the
following example.</
para>
/users?_queryFilter=userName+gt+"tt"&_fields=userName&_prettyPrint=true'
"userName" : "ttully@example.com"
"userName" : "tward@example.com"
"userName" : "wlutz@example.com"
"pagedResultsCookie" : null,
"remainingPagedResults" : -1
<
term><
literal><
replaceable>json-pointer</
replaceable> ge <
replaceable>json-value</
replaceable></
literal></
term>
<
para>Matches when the pointer is greater than or equal to the value,
as in the following example.</
para>
/users?_queryFilter=userName+ge+"tw"&_fields=userName&_prettyPrint=true'
"userName" : "tward@example.com"
"userName" : "wlutz@example.com"
"pagedResultsCookie" : null,
"remainingPagedResults" : -1
<
term>Presence expression</
term>
<
para><
literal><
replaceable>json-pointer</
replaceable> pr</
literal> matches
any resource on which the <
replaceable>json-pointer</
replaceable> is
present, as in the following example.</
para>
/users?_queryFilter=userName%20pr&_prettyPrint=true'
"_rev" : "000000002210a544",
"schemas" : [ "urn:scim:schemas:core:1.0" ],
"displayName" : "Sam Carter"
"telephoneNumber" : "+1 408 555 9445",
"emailAddress" : "abarnes@example.com"
"givenName" : "Anne-Louise"
"userName" : "abarnes@example.com",
"displayName" : "Anne-Louise Barnes"
},… many entries omitted …
"userName" : "newuser@example.com",
"displayName" : "New User",
"created" : "2013-03-26T10:52:42Z"
"pagedResultsCookie" : null,
"remainingPagedResults" : -1
<
term>Literal expressions</
term>
<
para><
literal>true</
literal> matches any resource in the collection.</
para>
<
para><
literal>false</
literal> matches no resource in the collection.</
para>
<
para>In other words you can list all resources in a collection as in the
following example.</
para>
/groups?_queryFilter=true&_fields=displayName&_prettyPrint=true'
"displayName" : "Accounting Managers"
"displayName" : "Directory Administrators"
"displayName" : "HR Managers"
"displayName" : "PD Managers"
"displayName" : "QA Managers"
"pagedResultsCookie" : null,
"remainingPagedResults" : -1
<
term>Complex expressions</
term>
<
para>You can combine expressions using boolean operators
<
literal>and</
literal>, <
literal>or</
literal>, and <
literal>!</
literal>
(not), using parentheses,
<
literal>(<
replaceable>expression</
replaceable>)</
literal>, to group
expressions. The following example queries resources with last name
Jensen and manager name starting with <
literal>Bar</
literal>. Notice that
the filters use the JSON pointers <
literal>
name/
familyName</
literal> and
nested inside the <
literal>name</
literal> and <
literal>manager</
literal>
&_fields=displayName&_prettyPrint=true'
"displayName" : "Jody Jensen"
"displayName" : "Ted Jensen"
"pagedResultsCookie" : null,
"remainingPagedResults" : -1
<para>You can have the server sort JSON resources before it returns them by using the <literal>_sortKeys[+-]=<replaceable>field</replaceable>[,…]</literal> <para>You can page through search results using the following query string <term><literal>__pagedResultsCookie=<replaceable>string</replaceable></literal></term> <term><literal>__pagedResultsOffset=<replaceable>string</replaceable></literal></term> <term><literal>__pagedResultsCookie=<replaceable>string</replaceable></literal></term>