The specific calls are described in Standard CRUD+L APIs for CollectionSpace services, below.

Payloads

Payloads - data that you will send in some of your requests to the services, and that you will receive in some of your responses from the services - share some common characteristics:

Payloads for individual records

Payloads for individual records in most CollectionSpace services are extensible. Extensibility is provided by bundling multiple parts for each record in Create, Read and Update operations: a "core" part, a "common" part, and zero or more optional extension parts. Details regarding this:

• With each service that supports extensible schema, the payloads you will send and receive for individual resources, in Create, Read and Update operations, are XML documents, with a Content-Type header of application/xml. (Note that Delete operations don't exchange a payload in the body of the request.) Each field in an object or procedural record is usually represented by a corresponding element in that XML document.
  
  Payloads consist of one or more parts, each contained within separate XML elements:
  • Each part is associated with one of the layered schemas, as described in the Schema Extension documentation:
  • There will be:
    • One core part. This part contains metadata about the record, such as when, and by whom, it was created and last modified. Fields in this part are set internally when a record is created, and the updatedAt and updatedBy fields are refreshed each time the record is updated. The core part is read-only; if an incoming payload includes this part, its values will be ignored.
    • One common part. This part contains the set of standard (or "common") fields for the CollectionSpace record of that type (e.g. CollectionObjects, Acquisitions, LoansOut ...)
    • Zero or more optional extension parts. Each extension part, if any, will contain a set of new fields that extend the standard CollectionSpace record type. Extension parts may in turn be associated with a "domain" (containing fields defined by a community of museums or a similar body, and often associated with a specific discipline such as fine arts, anthropology, or botany) or be a "local" part (containing fields unique to your own museum).
  • Some response payloads may also return an additional part or parts, such as a part containing information about related resources.

• With each service that does not support extensible schema, or where the request or response contains the payload only from a single schema, the payloads that you will send and receive for individual resources, in Create, Read and Update operations, will typically be an XML document, with a Content-type header of application/xml. Each field in an object or procedural record is usually represented by a corresponding element in that XML document.
  
  Some notable examples of services that do not support extensible schema are the Account service, Authorization service, and the ID service. List operations also follow this model (see below).
  
  (In the case of just the ID service, payloads of text/plain are currently returned by one Read operation: that of retrieving new IDs. This may later change to an XML-based payload, for uniformity with other services.)

Payloads for lists

When you directly request a list of resources, or when a list of resources is returned in response to a search, partial term match, request for related authorities, or similar operations, the payload you will receive will be an XML document, with a Content-type header of application/xml.

Each item in the list will be contained within an 'item'-type element, whose name will vary. 

 Each item in a list contains compact, summary information for each resource. This summary information will typically contain one or two displayable fields, as well as the identifier and URL for retrieving the full record for that item. 

For more information on lists and list payloads, see List results, pagination controls and search.

Sparse payloads

The services support "sparse" payloads, which contain only a subset of the fields listed in the schema for a record type.

When creating or updating an individual record (or resource), any fields not passed in the payload will not be affected:

• On create, missing/unspecified values will take default values - usually null.
• On update, missing/unspecified values will not be changed (except subject to validation rules).

When reading a record (or resource), only fields that have non-null values - populated by a prior create or update, or by a service itself - will be returned. Fields containing null values will not be returned.

Repeatable fields and field groups

The services support repeatable (also known variously as multivalued, multivalue, or repeating) fields and field groups.

For some record types, it is specified that:

• Certain fields can optionally be repeated (that is, occur more than once).
• Certain groups of fields can optionally be repeated.
• Within a group of fields that can be repeated, certain fields in that group can themselves optionally be repeated.
• Entire Information Groups can be repeated.

A repeatable field is represented in payloads in the form of a parent field, which acts solely as a container, and zero or more instances of a repeatable child field. Example:

<acquisitionSources>
  <acquisitionSource>urn:cspace:org.collectionspace.demo:personauthority:id(TestPersonAuthority):item:name(SallyKRide)'Sally K. Ride'</acquisitionSource>
  <acquisitionSource>urn:cspace:org.collectionspace.demo:personauthority:id(TestPersonAuthority):item:name(RobertLCrippen)'Robert L. Crippen'</acquisitionSource>
  <acquisitionSource></acquisitionSource>
  ...
</acquisitionSources>

As shown in the example above, it is permissible to create or update an instance of a repeatable field with a value that is empty (blank).

A repeatable group of fields is represented in payloads in the form of a grandparent "list" field, which acts solely as a container; a parent "group" field, which also acts solely as a container, and zero or more instances of the fields within that group. Example (to show structure only; this is not an example from any CollectionSpace record type):

<aGroupList>
  <aGroup>
    <field1>value</field1>
    <field2>value</field2>
  </aGroup>
  <aGroup>
    <field2>value</field2>
    <field3>value</field3>
    <field5>value</field5>
  </aGroup>
  ...
</aGroupList>

Authentication

Authentication is required to call CollectionSpace REST services. CollectionSpace REST services use HTTP Basic Authentication with HTTPS server side authentication. An authentication token for the end user must be provided in the HTTP header.

The HTTP error code 401 (Unauthorized) with response message is used by the CollectionSpace services to challenge the authorization of a user agent. Upon receipt of an unauthorized request for a URI within the CollectionSpace protection space, the server will respond with a challenge like the following:

WWW-Authenticate: Basic realm="org.collectionspace.services"

In response, the user agent could send an authentication token, consisting of the userid and password Base64 encoded as follows:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Where QWxhZGRpbjpvcGVuIHNlc2FtZQ== is an example of userid:password in Base64 encoded form. Note that in the authentication token, the userid and password are delimited (separated) by a colon character (:), prior to being Base64 encoded. Refer to HTTP Basic Authentication for more details.

In a future release of the CollectionSpace system, the calling application may also be required to provide an authorized application ID.

List results, filtering, pagination controls, sorting and search

List results

All REST services allow you to obtain lists of items. Each item in a list contains compact, summary information for each resource. This summary information will typically contain one or two displayable fields, as well as the identifier and URL for retrieving the full record for that item.

In the future, it may be possible to configure and/or more flexibly specify the fields returned in summary information, for export and other purposes.

List pagination

Most REST services that provide lists of results also support pagination of the results. Rather than receiving many thousands of records upon a GET request for, say, cataloging records, you can instead request a single "page" of the list, containing a smaller subset of those records, and then you can 'page through' the entire list.

You can control how many records are returned per page, and which page of records to retrieve, by adding query parameters onto your GET request:

• pgSz indicates the number of results to return per page.
  • If pgSz is not provided, the default behavior will return 40 items on each page of the list results (with the potential ability in the future to be able to configure this centrally and/or per service).

  • pgSz has a maximum value of 1000 (should probably support configuration of this as well).

    This maximum needs to be verified. I could not find a maximum constant or configured value, and was able to retrieve 2000 person items on Nightly by setting pgSz=2000, with a total dataset of 2064 such records. (See CSPACE-4970.)

  • Setting pgSz=0 will return up to the maximum number of items, on a single page. (When large numbers of items will be returned, the response to a pgSz=0 request may be somewhat slow.)
• pgNum indicates the page number to return. This leverages the pgSz value to produce the starting offset for the returned results.
  • If pgNum is not provided, the default behavior will return the first page (page 0, as discussed below) of the list results.
  • Pages are zero-based; you can request the first page of results via pgNum=0, the second page via pgNum=1, and so on.

The list schemas for these services include information about the pagination before the list items:

• The <pageNum> element reflects the pgNum request made (0, by default)
• The <pageSize> element reflects the pgSz request made, or the default page size.
• The <itemsInPage> element reflects the total number of items in the current page.
• The <totalItems> element reflects the total number of items found for the list or search query.
• The <fieldsReturned> element identifies the fields returned within each list item. The value of that element consists of a pipe-delimited ("|") list of field names.

Filtering on workflow state

Most REST services that provide lists of results support filtering on workflow state.

By default, all records are returned in list results, regardless of workflow state. Optionally, you can specify that records matching a particular workflow state, or states, will be excluded from list results.

The sole workflow state on which you can currently filter records is the "soft" deleted state. A record that has been "soft" deleted has been marked for deletion, but the record and its data still exist.

To exclude records in the "soft deleted" state from list results, so that only active (non-deleted) records are returned, add the following query parameter to your GET request:

?wf_deleted=false

(In addition, individual records in the "soft deleted" state can also be excluded from being returned from results. See Common Services REST API documentation#Read an object/procedure/record instance for details.)

Sorting

Most REST services that provide lists of results also support sorting of the results. You can specify the field on which to sort by adding query parameters onto your GET request:

sortBy indicates the field on which to sort. The value of this parameter takes a schema name, a colon (':') as a delimiter, and a field name within that schema, as defined by the services. Examples:

?sortBy=collectionobjects_common:distinguishingFeatures

?sortBy=collectionobjects_local:myCustomField

The second example above sorts on a custom field, within a museum's local schema for a collection object - in this hypothetical example named "collectionobjects_local".

By default, sorted results are returned in ascending order: from first to last. "Empty" (null or empty string) values are returned in sort order before non-empty values. To sort in descending order, add "+DESC" to the end of the field name. Example:

?sortBy=movements_common:locationDate+DESC

To sort on more than one field, separate each sort field with ,+. Example:

?sortBy=movements_common:locationDate+DESC,+movements_common:movementNote

Records will be ordered by the first sort field provided; then, within that ordering, by the second sort field, and so on. In the example above, records will first be sorted by their location date fields in descending order; then, in cases where there are multiple records with identical location dates, they will be sorted by their movement note fields in ascending order.

In contrast with pagination details, details regarding the sort order used are not currently returned in the list results. These are scheduled to be added in a future release.

Search (query)

Some services support search (query) methods to return matching items, e.g., partial matches against a name, or matches against a keyword index. These return results as for the basic list operation, but filtered according to the query parameters. The query parameters are specific to each service, although certain patterns will be seen:

• For those services that support keyword index search, the query parameter "kw=term" specifies the keyword on which to search.
• For those services (primarily Authorities and Vocabularies) that support partial term matching (aka term suggestion or term completion search), the query parameter "pt=term" specifies the partial term to match.
• For those services (primarily Authorities and Vocabularies) that support termStatus filtering (aka filtering results based upon termStatus values), the query parameter "ts=term1|term2" specifies the list of terms to match. Note that the separator ('|') is URL encoded as %7C.

Related records

In a CollectionSpace system, with only a few exceptions, any two records can be related to one another. Some representative examples:

• Multiple Cataloging / CollectionObject records can be related to an Intake, Acquisition, Loan In, Loan Out, or Object Exit record.
• Similarly, multiple Location/Movement/Inventory records can be related to a Cataloging / CollectionObject record.

Some records can also be hierarchically related to one another. Some representative examples:

• Multiple Cataloging / CollectionObject records can be related in a hierarchy. Each record can optionally be related to one Broader Object (its immediate parent) and/or one or more Object Components (its immediate children).

• Multiple authority term records can be related in a hierarchy. Each term can optionally be related to one Broader Context term (its immediate parent) and/or one or more Narrower Context terms (its immediate children).
  A sample three-level authority term hierarchy:

  Broader Context	Term	Narrower Context
  -	North America	Canada
  North America	Canada	Ontario Quebec
  Canada	Ontario	-
  Canada	Quebec	-

There are three different categories of REST API calls to return related records. The calls in two of these categories each return lists of Relation records, the "linking" records that relate any two other types of records. Calls in the third category, in contrast, directly return lists of records of a particular type that are related to the specified record. 

See Common Services REST API documentation#List related records for more details.

Standard CRUD+L APIs for CollectionSpace services

Except as noted in individual service REST API documentation, the CollectionSpace services support the following calls.

• Common Services REST API documentation#Create an object/procedure/record instance
• Common Services REST API documentation#Read an object/procedure/record instance
• Common Services REST API documentation#Update an object/procedure/record instance
• Common Services REST API documentation#Delete an object/procedure/record instance
• Common Services REST API documentation#List All object/procedure/record instances
• Common Services REST API documentation#Keyword Search for object/procedure/record instances
• Common Services REST API documentation#Partial Term Matching for object/procedure/record instances
• Related Authority References for (aka Terms Used by) object/procedure/record instances
• Common Services REST API documentation#Read workflow state of an object/procedure/record instance
• Common Services REST API documentation#Update workflow state of an object/procedure/record instance
• Common Services REST API documentation#List related records

Create an object/procedure/record instance

Creates a new object/procedure/record instance. Assigns a unique, service-specified CollectionSpace ID (CSID) to that record. Standard authentication applies, and user must have create privileges for the associated object/procedure/record type.

Calling method and Arguments

Create is invoked as an HTTP POST method on a collection of service resources or sub-resources (e.g. ../collectionobjects/ or ../personauthorities/{csid}/persons/). The RESTful metaphor is that of creating a new record within a container, or 'bucket', of records of that type.

The body of your Create request contains the data that will be used to create a new record. In most cases, you'll be sending an XML document consisting of one or more parts, with each part contained within its own XML element.

An example of a Create request to the CollectionObject service follows below. See each individual service's API documentation for further details:

POST /cspace-services/collectionobjects HTTP/1.1
Content-Type: application/xml
Content-Length: nnnn
 
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<document name="collectionobjects">
<ns2:collectionobjects_common xmlns:ns2="http://collectionspace.org/services/collectionobject">
  <objectNumber>objectNumber-1266005065536</objectNumber>
  <briefDescription>
     Papier mache bird cow mask with horns, painted red with black and yellow spots.
     Puerto Rico. ca. 8&quot; high, 6&quot; wide, projects 10&quot; (with horns).
  </briefDescription>
  <objectName>objectName-1266005065536</objectName>
  ...
</ns2:collectionobjects_common>
<ns2:collectionobjects_naturalhistory
     xmlns:ns2="http://collectionspace.org/services/collectionobject/domain/naturalhistory">
  <nh-string>test-string</nh-string>
  <nh-int>999</nh-int>
  <nh-long>9999</nh-long>
</ns2:collectionobjects_naturalhistory>
</document>

Create service calls do not generally accept query parameters or other arguments.

Any XML document(s) included in your Create request must be a valid XML representation of the associated object/procedure/record that you wish to create. This may be a sparse payload, containing only selected fields. Each service has a different schema (record format); for details, please see the individual service's documentation.

Responses

On success, a response with a "201 Created" HTTP status code is returned. Note that the Location: header will contain the service path, including the CollectionSpace ID (CSID), to the newly created resource, as in this example:

HTTP/1.1 201 Created
Content-Type: application/xml
Location: https://demo.collectionspace.org/cspace-services/collectionobjects/a4b65c82-0eb8-41ec-8936
Content-Length: nnnn
...

If an error occurred, some non-2xx code will be returned. Check the HTTP Status Code that is returned in the response's HTTP headers for the specific error.

The following errors may be returned in response to Create requests. Your code should check for each of these, while noting that not every CollectionSpace service may currently return all of the errors below:

Read an object/procedure/record instance

Gets (reads) information about a single object/procedure/record instance, specified by its CollectionSpace ID (CSID) as returned by Create, or a List method. Standard authentication applies, and user must have read privileges for the associated object/procedure/record type.

Calling method and Arguments

Read is invoked as an HTTP GET method on a specific instance of a resource, qualified with a CSID value. Send an HTTP request of the form (the specific path is only an example - the appropriate path is documented in each service API):

GET /cspace-services/collectionobjects/{csid} HTTP/1.1

Most read service calls accept a single, optional query parameter:

GET /cspace-services/collectionobjects/{csid}?wf_deleted=false HTTP/1.1

If this parameter is included, a record that has been "soft" deleted will not be returned by the Read request. Instead, a 404 Not Found status code will be returned in the response.

Responses

On success, a response with a "200 OK" HTTP status code and a representation of the requested object/procedure/record record is returned, with the associated schema sections represented, as below. See the individual service documentation for schema details.

HTTP/1.1 200 OK
Content-Type: application/xml
Content-Length: nnnn
 
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<document name="collectionobjects">
<ns2:collectionspace_core xmlns:ns2="http://collectionspace.org/collectionspace_core/"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <updatedAt>2011-08-02T21:08:33Z</updatedAt>
    <createdAt>2011-07-29T18:03:56Z</createdAt>
    ...
</ns2:collectionspace_core>
<ns2:collectionobjects_common xmlns:ns2="http://collectionspace.org/services/collectionobject">
  <objectNumber>objectNumber-1266005065536</objectNumber>
  <briefDescription>
     Papier mache bird cow mask with horns, painted red with black and yellow spots.
     Puerto Rico. ca. 8&quot; high, 6&quot; wide, projects 10&quot; (with horns).
  </briefDescription>
  <objectName>objectName-1266005065536</objectName>
  ...
</ns2:collectionobjects_common>
<ns2:collectionobjects_naturalhistory
     xmlns:ns2="http://collectionspace.org/services/collectionobject/domain/naturalhistory">
  <nh-string>test-string</nh-string>
  <nh-int>999</nh-int>
  <nh-long>9999</nh-long>
</ns2:collectionobjects_naturalhistory>
</document>

If an error occurred, some non-2xx code will be returned. Check the HTTP Status Code that is returned in the response's HTTP headers for the specific error.

The following errors may be returned in response to Read requests. Your code should check for each of these, while noting that not every CollectionSpace service may currently return all of the errors below:

Update an object/procedure/record instance

Updates an individual object/procedure/record instance, specified by its CollectionSpace ID (CSID) as may be returned by Create, or by a List method. Standard authentication applies, and user must have update privileges for the associated object/procedure/record type.

Calling method and Arguments

Update is invoked as an HTTP PUT method on an instance of a resource or sub-resource, qualified with a CollectionSpace ID (CSID) value (e.g. ../collectionobjects/{csid} or ../personauthorities/{csid}/persons/{csid}).

The body of your Update request contains the data that will be used to update the existing record. In most cases, you'll be sending an XML document consisting of one or more parts, with each part contained within its own XML element.

An example of an Update request to the CollectionObject service, to update the contents of the record whose CollectionSpace ID (CSID) is 850161ed-466c-4af2-bc45, follows below. See each individual service's API documentation for further details:

PUT /cspace-services/collectionobjects/850161ed-466c-4af2-bc45 HTTP/1.1
Content-type: application/xml
Content-Length: nnn
 
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<document name="collectionobjects">
<ns2:collectionobjects_common
     xmlns:ns2="http://collectionspace.org/services/collectionobject">
  <objectNumber>updated-objectNumber-1266003498657</objectNumber>
  <objectName>updated-objectName-1266003498657</objectName>
  ....
</ns2:collectionobjects_common>
</document>

Update service calls do not generally accept query parameters or other arguments.

Any XML document(s) included in your Update request must be a valid XML representation of the associated object/procedure/record whose contents you wish to update. This may be a sparse payload, containing only selected fields. Each service has a different schema (record format); for details, please see the individual service's documentation.

As a general rule, if the XML document(s) included in the payload of your Update request include one or more elements that have child elements, the update will completely replace (i.e. overwrite) the existing child elements with the new child elements, if any, you are sending. This means, for example, to update the contents of a multi-valued field, you will send an update request containing a new set of values for that field. To remove all of the values from a multi-valued field, you will send an update request containing no values for that field. For any per-service exceptions to this behavior, please see the individual service's documentation.

Responses

On success, a response with a "200 OK" HTTP status code and a representation of the updated object/procedure/record instance is returned. The body of the response is the same as for the standard read operation; see Common Services REST API documentation#Read an object/procedure/record instance.

HTTP/1.1 200 OK
Content-Type: application/xml
Content-Length: nnnn
 
 
<document name="collectionobjects">
<ns2:collectionspace_core xmlns:ns2="http://collectionspace.org/collectionspace_core/"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <updatedAt>2011-08-02T23:15:06Z</updatedAt>
    ...
</ns2:collectionspace_core>
<ns2:collectionobjects_common
    xmlns:ns2="http://collectionspace.org/services/collectionobject"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="...">
  <objectNumber>updated-objectNumber-1266003498657</objectNumber>
  <title>atitle</title>
  <briefDescription>Papier mache bird cow mask with horns, painted red with black and yellow spots.
    Puerto Rico. ca. 8&quot; high, 6&quot; wide, projects 10&quot; (with horns).
  </briefDescription>
  <objectName>updated-objectName-1266003498657</objectName>
  ...
</ns2:collectionobjects_common>
<ns2:collectionobjects_naturalhistory
     xmlns:ns2="http://collectionspace.org/services/collectionobject/domain/naturalhistory">
  <nh-string>test-string</nh-string>
  ...
</ns2:collectionobjects_naturalhistory>
</document>

If an error occurred, some non-2xx code will be returned. Check the HTTP Status Code that is returned in the response's HTTP headers for the specific error.

The following errors may be returned in response to Update requests. Your code should check for each of these, while noting that not every CollectionSpace service may currently return all of the errors below:

Delete an object/procedure/record instance

Deletes an individual object/procedure/record instance, specified by its CollectionSpace ID (CSID) as returned by Create, or a List method. Standard authentication applies, and user must have delete privileges for the associated object/procedure/record type.

Calling method and Arguments

Delete is invoked as an HTTP DELETE method on an instance resource (the primary service resource qualified with a CSID value). Send an HTTP request of the form (the specific path is only an example - the appropriate path is documented in each service API):

DELETE /cspace-services/collectionobjects/{csid} HTTP/1.1

Delete service calls do not generally accept query parameters or other arguments.

On success, a response with a "200 OK" HTTP status code is returned, with an empty entity body:

HTTP/1.1 200 OK
Content-Length: 0
...

If an error occurred, some non-2xx code will be returned. Check the HTTP Status Code that is returned in the response's HTTP headers for the specific error.

The following errors may be returned in response to Delete requests. Your code should check for each of these, while noting that not every CollectionSpace service may currently return all of the errors below:

List All object/procedure/record instances

Gets summary information about all instances for the associated resource. Instances for which the authenticated user does not have read privileges, will not be returned in results.

Each item in a list contains compact, summary information for each resource. This summary information will typically contain at least one or two displayable fields, as well as the identifier and URL for retrieving the full record for that item. 

Summary information generally includes the CollectionSpace ID (CSID) of each instance, which can be included in the URIs of subsequent requests in order to read, update, or delete specific instances. The specific information returned within the items of a list is documented with each service resource, and may include displayName or refName information for each item.

Calling method and Arguments

List is invoked as an HTTP GET method on the primary resource. Send an HTTP request of the form (the specific path is only an example - the appropriate path is documented in each service API):

GET /cspace-services/collectionobjects HTTP/1.1

As described in the intro above, and unless noted in the specific service, List service calls support pagination of results. E.g., to get the third page of results with 20 results per page, send an HTTP request of the form (the specific path is only an example - the appropriate path is documented in each service API):

GET /cspace-services/collectionobjects?pgSz=20&pgNum=2 HTTP/1.1

On success, a response with a "200 OK" HTTP status code is returned (note the pagination-info elements):

HTTP/1.1 200 OK
Content-Type: application/xml
Content-Length: nnnn
 
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:abstract-common-list xmlns:ns2="http://collectionspace.org/services/jaxb">
  <pageNum>2</pageNum>
  <pageSize>20</pageSize>
  <totalItems>53</totalItems>
  <fieldsReturned>objectNumber|objectName|title|responsibleDepartment|uri|csid</fieldsReturned>
  <list-item>
    <objectNumber>objectNumber-1304508705716</objectNumber>
    <objectName/>
    <title>title-1304508705716</title>
    <responsibleDepartment/>
    <uri>/collectionobjects/18acadbf-8e89-4520-a1f9</uri>
    <csid>18acadbf-8e89-4520-a1f9</csid>
  </list-item>
  <list-item>
    <objectNumber>objectNumber-1304508708473</objectNumber>
    <objectName/>
    <title>title-1304508708473</title>
    <responsibleDepartment/>
    <uri>/collectionobjects/c3deb7f9-3882-46d1-b79e</uri>
    <csid>c3deb7f9-3882-46d1-b79e</csid>
  </list-item>
  ...
</ns2:abstract-common-list>

The names of the root element and of the item elements in the list may vary between services. As of CollectionSpace version 1.9, most services return abstract-common-list as the name of the root element in the list and list-item as the name of each item element in the list.

If no individual object/procedure/record instances are found, a response with a "200 OK" HTTP status code, containing pagination information and an empty list - a list with only a root element, but no child elements - is returned.

If an error occurred, some non-2xx code will be returned. Check the HTTP Status Code that is returned in the response's HTTP headers for the specific error.

Keyword Search for object/procedure/record instances

Searches on one or more keywords, and returns summary information about all instances of the associated resources which are matched by those keywords.

Instances for which the authenticated user does not have read privileges, will not be returned in results.

Summary information generally includes the CollectionSpace ID (CSID) of each instance, which can be included in the URIs of subsequent requests in order to read, update, or delete specific instances. The specific information returned within the items of a list is documented with each service resource, and may include displayName or refName information for each item. Note that the summary information returned often provides no indication of where your keywords were found in the record(s) returned.

How keyword search works

Keyword searches:

• Search the full text of all fields. See the "Keyword search caveats" section below for some "gotchas" related to this.
• Are case-insensitive.
• When multiple keywords are included in the query:
  • By default, the search is carried out as though a Boolean AND is present between each keyword pair. For instance, a search for "tea" may return records having "tea set" and "tea kettle", and a search for "set" may return "tea set" and "coffee set", but a search for "tea+set" would include records having "tea set" (as well as "set tea" and "the tea was only sold as part of a sampler set").
  • You may include the OR operator in your query if you would like that behavior. A query for "tea+OR+set" would return records having "tea set", "tea kettle", and "coffee set".
  • Order of the terms is irrelevant. For example, a record containing the option list value "architecture-design" will be retrieved if you search for "architecture+design" or "design+architecture"
• Will not match a database-dependent list of stopwords. (See, for example, Issue CSPACE-807.) If your query consists only of a stopword (e.g. "A."), no results are returned. If your multiple-term query contains a stopword, that term is dropped. For example, a Person authority query for "Jane+A.+Doe" would return records containing "Jane Doe", "Jane P. Doe", and "Jane A. Doe" because it is just searching for the presence of "Jane" and "Doe".
• Matches whole tokens. For instance, a keyword search or Person authorities for "Q" will return only names like "John Q. Public". "Quinn Jones" would not be included in the results, even though the name contains a "Q". That said, some level of stemming is applied. For example, a keyword search for "designs" will retrieve records having the option list value "architecture-design", without "designs" literally appearing in the records.

Normalization/tokenization

The keyword index performs some normalization and tokenization of the record data. For example, the option list value "architecture-design" is split into "architecture" and "design". Some normalization/tokenization is performed on query parameters passed in, but the processing does not exactly match the normalization/tokenization used for the index. For example, a keyword search for "architecture-design" will retrieve nothing.

Diacritics are not normalized. For example, to retrieve a record containing "Le Chat Qui Pêche", you must search for "pêche". A search for "peche" will not retrieve the record.

Repeatable fields

Values in repeatable fields are searched. Note, however, that there is no requirement that values in repeatable groups or subgroups must appear together in one grouping for a record to be retrieved.

A record containing the repeatable field group shown below would be returned in the keyword search results for "979899+lender".

<otherNumberList>
  <otherNumber>
    <numberType>previous</numberType>
    <numberValue>979899</numberValue>
  </otherNumber>
  <otherNumber>
    <numberType>lender</numberType>
    <numberValue>12131417</numberValue>
  </otherNumber>
</otherNumberList>

A record containing the repeatable field subgroup data shown below would be returned in the keyword search results for "english+pescador".

<titleGroupList>
    <titleGroup>
        <titleTranslationSubGroupList>
            <titleTranslationSubGroup>
                <titleTranslation>Le Chat Qui Pêche</titleTranslation>
                <titleTranslationLanguage>urn:cspace:core.collectionspace.org:vocabularies:name(languages):item:name(fra)'French'</titleTranslationLanguage>
            </titleTranslationSubGroup>
            <titleTranslationSubGroup>
                <titleTranslation>El gato pescador</titleTranslation>
                <titleTranslationLanguage>urn:cspace:core.collectionspace.org:vocabularies:name(languages):item:name(spa)'Spanish'</titleTranslationLanguage>
            </titleTranslationSubGroup>
        </titleTranslationSubGroupList>
        <titleType>popular</titleType>
        <titleLanguage>urn:cspace:core.collectionspace.org:vocabularies:name(languages):item:name(eng)'English'</titleLanguage>
        <title>Fishing cat</title>
    </titleGroup>
</titleGroupList>

Keyword search caveats

Data in some non-displayed system fields is searched

The full text of records searched by keyword search includes some system fields not displayed in the UI. This means that keywords that appear in the uri field ("items"), or refName field (“name”, “item”) may match large numbers of unexpected records, depending on the record type being searched.

The underlying data stored in the record is searched, not necessarily what you see displayed in the UI

Option list/static list values

If an option list value is defined as one "keyword" and its message is multiple words, searching on words from the message will not retrieve records as expected. For the loanPurposes option shown below, you cannot retrieve loans for this purpose by keyword searching for "scientific". You must search for the whole "word" representing the option in the underlying data: "scientificorexhibitpreparation".

If this option value had been defined as "scientific-or-exhibit-preparation", it would be tokenized into separate words and records containing this value would be retrievable by a keyword search for "scientific".

scientificorexhibitpreparation: {
  id: 'option.loanPurposes.scientificorexhibitpreparation',
  defaultMessage: 'scientific or exhibit preparation',
}

Authority term values

You may have a Person authority record where the first Display Name value is "Jane Doe" and one of the subsequent Display Name values is for the variant name "Janey Doe". If you do a keyword search for "Janey+Doe" on that Person authority, you will retreive the record as expected.

However, if you search collectionobjects for "Janey+Doe", you will not retrieve any results because only the term's refName value, which contains only the first Display Name value from the authority, is in the underlying data in a collectionobject record.

Calling method and Arguments

Keyword search is invoked as an HTTP GET method on the primary resource, including a specific query parameter (kw=) to indicate that a keyword search is being performed, and providing a list of zero or more keywords to be used in the search as arguments to that query parameter.

Send an HTTP request of the form (the specific path is only an example - the appropriate path is documented in each service API):

GET /cspace-services/collectionobjects?kw=cucurbita HTTP/1.1

To search on multiple keywords, add a plus sign ("+") between each keyword:

GET /cspace-services/collectionobjects?kw=whetstone+sharpening+sharpen HTTP/1.1

On success, a response with a "200 OK" HTTP status code is returned. The payload that is returned from a keyword search is identical to the payload returned from a List All request:

HTTP/1.1 200 OK
...
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:abstract-common-list xmlns:ns2="http://collectionspace.org/services/jaxb">
    <pageNum>0</pageNum>
    <pageSize>40</pageSize>
    <itemsInPage>2</itemsInPage>
    <totalItems>2</totalItems>
    <fieldsReturned>csid|uri|refName|updatedAt|workflowState|objectNumber|objectName|title|responsibleDepartment</fieldsReturned>
    <list-item>
        <csid>77c07515-c0e3-4b76-aeea</csid>
        <uri>/collectionobjects/77c07515-c0e3-4b76-aeea</uri>
        <refName>urn:cspace:core.collectionspace.org:collectionobjects:id(77c07515-c0e3-4b76-aeea)'Coffee set'</refName>
        <updatedAt>2022-01-31T21:34:52.301Z</updatedAt>
        <workflowState>project</workflowState>
        <objectNumber>Coffee set</objectNumber>
        <objectName>Beverage serving</objectName>
        <title>Fancy coffee set</title>
        <responsibleDepartment>decorative-arts</responsibleDepartment>
    </list-item>
    <list-item>
        <csid>bf51110a-0666-47b8-b9d4</csid>
        <uri>/collectionobjects/bf51110a-0666-47b8-b9d4</uri>
        <refName>urn:cspace:core.collectionspace.org:collectionobjects:id(bf51110a-0666-47b8-b9d4)'Tea Set'</refName>
        <updatedAt>2021-10-15T01:43:56.437Z</updatedAt>
        <workflowState>project</workflowState>
        <objectNumber>Tea Set</objectNumber>
    </list-item>
</ns2:abstract-common-list>

If no object/procedure/record instances match the keyword(s) provided, a response with a "200 OK" HTTP status code, containing an empty list - a list with only a root element, but no child elements - is returned.

If an error occurred, some non-2xx code will be returned. Check the HTTP Status Code that is returned in the response's HTTP headers for the specific error.

Advanced Search for object/procedure/record instances

Searches using a provided search expression and returns summary information about all instances of the associated resources which are matched by that expression.

Instances for which the authenticated user does not have read privileges, will not be returned in results.

Summary information generally includes the CollectionSpace ID (CSID) of each instance, which can be included in the URIs of subsequent requests in order to read, update, or delete specific instances. The specific information returned within the items of a list is documented with each service resource, and may include displayName or refName information for each item.

Calling method and Arguments

Advanced search is invoked as an HTTP GET method on the primary resource, including a specific query parameter (as=) to indicate that an advanced search is being performed, and providing a search expression as the argument to that query parameter.

The search expression must be:

• A valid NXQL expression. (NXQL is the schema-aware query language used with CollectionSpace's Nuxeo repository, and its expressions are similar to standard SQL SELECT statements. See Nuxeo's NXQL search documentation.)
• URL encoded.

Send an HTTP request of the form (the specific path is only an example - the appropriate path is documented in each service API) shown in these representative examples:

GET /cspace-services/loansin?as=loansin_common%3AloanPurpose%20ILIKE%20%27%25research%25%27

Written with easier-to-read, non-URL encoded values:
?as=loansin_common:loanPurpose ILIKE '%research%'

GET /cspace-services/loansin?as=loansin_common%3AloanInNumber%20LIKE%20%27LI2012%25%27

Written with easier-to-read, non-URL encoded values:
?as=loansin_common:loanInNumber LIKE 'LI2012%'

GET /cspace-services/intakes?as=intakes_common%3Adepositor%3D%22urn%3Acspace%3Acore.collectionspace.org%3Apersonauthorities%3Aname%28person%29%3Aitem%3Aname%28JohnDoe1327373674139%29%27John+Doe%27%22

Written with easier-to-read, non-URL encoded values: ?as=intakes_common:depositor="urn:cspace:core.collectionspace.org:personauthorities:name(person):item:name(JohnDoe1327373674139)'John Doe'"
(the double quote marks around the refName are required in this instance, to enclose the single quote marks in the display name portion of the refName)

GET /cspace-services/collectionobjects?as=collectionspace_core%3AupdatedAt+%3E%3D+TIMESTAMP+%222012-01-17T00%3A00%3A00%22+AND+collectionspace_core%3AupdatedAt+%3C%3D+TIMESTAMP+%222012-01-31T23%3A59%3A59%22

Written with easier-to-read, non-URL encoded values:
?as=collectionspace_core:updatedAt >= TIMESTAMP "2012-01-17T00:00:00" AND collectionspace_core:updatedAt <= TIMESTAMP "2012-01-31T23:59:59"

GET /cspace-services/media?as=media_common%3AdateGroupList%2F*%2FdateEarliestScalarValue+%3E%3D+TIMESTAMP+%222011-02-17T00%3A00%3A00%22+AND+media_common%3AdateGroupList%2F*%2FdateLatestScalarValue+%3C%3D+TIMESTAMP+%222011-03-31T23%3A59%3A59%22

Written with easier-to-read, non-URL encoded values:
?as=media_common:dateGroupList/*/dateEarliestScalarValue >= TIMESTAMP "2011-02-17T00:00:00" AND media_common:dateGroupList/*/dateLatestScalarValue <= TIMESTAMP "2011-03-31T23:59:59"

For more details and additional examples, see the CollectionSpace documentation on advanced search.

On success, a response with a "200 OK" HTTP status code is returned. The payload that is returned from an advanced search is identical to the payload returned from a List All request.

HTTP/1.1 200 OK
...
<?xml version="1.0"?>
<abstract-common-list>
    <pageNum>0</pageNum>
    <pageSize>40</pageSize>
    <itemsInPage>1</itemsInPage>
    <totalItems>1</totalItems>
    <fieldsReturned>csid|uri|updatedAt|entryNumber|depositor|currentOwner</fieldsReturned>
    <list-item>
        <csid>0b72fec7-7b56-4d97-8fba</csid>
        <uri>/intakes/0b72fec7-7b56-4d97-8fba</uri>
        <updatedAt>2012-01-24T02:54:42Z</updatedAt>
        <entryNumber>EV2012.2</entryNumber>
        <depositor>urn:cspace:core.collectionspace.org:personauthorities:name(person):item:name(JohnDoe1327373674139)'John Doe'</depositor>
        <currentOwner/>
    </list-item>
</abstract-common-list>

If no object/procedure/record instances match the search expression provided, a response with a "200 OK" HTTP status code, containing an empty list - a list with only a root element, but no child elements - is returned.

If an error occurred, some non-2xx code will be returned. Check the HTTP Status Code that is returned in the response's HTTP headers for the specific error.

Partial Term Matching for object/procedure/record instances

Searches on a partial term. (This functionality may also sometimes be described as term suggestion or term completion.) Returns summary information about all instances of the associated resource that are matched by the partial term.

As an example, a partial term search on ally might match on Ally McBeal, June Ally son and W ally Van.

Note that, currently, partial term matching functionality is supported only by selected services:

• The Vocabulary service.
• The authority services (e.g. Person, Organization).

Instances for which the authenticated user does not have read privileges, will not be returned in results.

Summary information generally includes the CollectionSpace ID (CSID) of each instance, which can be included in the URIs of subsequent requests in order to read, update, or delete specific instances. The specific information returned within the items of a list is documented with each service resource, and may include displayName or refName information for each item.

Calling method and Arguments

Partial term matching is invoked as an HTTP GET method on the primary resource, including a specific query parameter and arguments to indicate that a partial term match is being performed, and providing the terms to be used in the match.

Send an HTTP request of the form (the specific path is only an example - the appropriate path is documented in each service API):

GET /cspace-services/collectionobjects?pt=jone HTTP/1.1

If the service offers access to a sub-resource, such as to the individual Organizations in an Organization Authority, partial term matching on the subresource uses a similar request syntax:

GET /cspace-services/orgauthorities/{csid}/items?pt=wildlife HTTP/1.1

On success, a response with a "200 OK" HTTP status code is returned. The payload that is returned from a partial term match is identical to the payload returned from a List All request:

HTTP/1.1 200 OK
...

If no object/procedure/record instances match the partial term provided, a response with a "200 OK" HTTP status code, containing an empty list - a list with only a root element, but no child elements - is returned.

If an error occurred, some non-2xx code will be returned. Check the HTTP Status Code that is returned in the response's HTTP headers for the specific error.

Term Status Filtering for Authority terms

Filters out returned terms based upon termStatus values. This may be combined with other searches, and so returns the same list results as other list and search operations. The parameter may specify one or more string values, corresponding to values set in the termStatus field of Authority items.

For those items that would otherwise be returned from the list or search operation, all items will be returned except those that have a termStatus matching any of the specified filter values. Those values will be excluded from the results.

Note that, currently, termStatus filtering functionality is supported only by selected services:

• The Vocabulary service.
• The authority services (e.g. Person, Organization).

Calling method and Arguments

Term status filtering is applied to search and list operations, and so is invoked as the corresponding HTTP GET methods on the associated resources:

GET /cspace-services/personauthorities/{csid}/items?ts=Rejected HTTP/1.1

GET /cspace-services/personauthorities/{csid}/items?pt=JoeBob&ts=Rejected HTTP/1.1

If an error occurred, some non-2xx code will be returned. Check the HTTP Status Code that is returned in the response's HTTP headers for the specific error.If all terms match on (e.g. are filtered out by) the termStatus values provided in the filter, a response with a "200 OK" HTTP status code, containing an empty list - a list with only a root element, but no child elements - is returned.

Related Authority References for object/procedure/record instances

Retrieves and returns all references to authorities found in an individual object or procedural record. (Stated another way, retrieves the authority terms used in a record, including the fields in which they are used, and provides links for accessing detailed information about each term.)

Instances for which the authenticated user does not have read privileges, will not be returned in results.

Calling method and Arguments

A call to retrieve related authority references is invoked as an HTTP GET method on the primary resource, followed by the "authorityrefs" path component. Send an HTTP request of the form (the specific path is only an example - the appropriate path is documented in each service API):

GET /cspace-services/intakes/{csid}/authorityrefs/ HTTP/1.1

On success, a response with a "200 OK" HTTP status code is returned, with a payload similar to the following example:

HTTP/1.1 200 OK
...
Content-Type: application/xml
Content-Length: nnn
 
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:authority-ref-list xmlns:ns2="http://collectionspace.org/services/common/authorityref">
  <authority-ref-item>
    <sourceField>depositor</sourceField>
    <refName>urn:cspace:org.collectionspace.demo:personauthority:id(6f58aea7-defd-45a2-910c):person:id(49b382e8-b23f-4142-ad53)'James+Adams'</refName>
    <itemDisplayName>James+Adams</itemDisplayName>
    <uri>/personauthorities/6f58aea7-defd-45a2-910c/items/49b382e8-b23f-4142-ad53</uri>
  </authority-ref-item>
  ...
</ns2:authority-ref-list>

In the above example, the 'depositor' field of the specified Intake resource has been identified as containing the term "James Adams", which in turn comes from a specified Person Authority. Information about that term can then be accessed via the path specified in the 'uri' field.

Some multivalued fields may contain more than one term. In those cases, multiple list items - one for each term found - will be returned for those fields.

If no related authority references are found in the record, a response with a "200 OK" HTTP status code, containing an empty list - a list with only a root element, but no child elements - is returned.

If an error occurred, some non-2xx code will be returned. Check the HTTP Status Code that is returned in the response's HTTP headers for the specific error.

Related Object References for authority items

Retrieves and returns all objects (procedures, etc) that reference a given authority item. Information returned includes an abstraction of the fields in which they are used.

Instances for which the authenticated user does not have read privileges, will not be returned in results.

Calling method and Arguments

A call to retrieve related authority references is invoked as an HTTP GET method on the authority item resource, followed by the "refObjs" path component. Send an HTTP request of the form (the specific path is only an example - the appropriate path is documented in each service API):

GET /cspace-services/personauthorities/urn:cspace:name(person)/items/{csid}/refObjs/ HTTP/1.1

On success, a response with a "200 OK" HTTP status code is returned, with a payload similar to the following example:

HTTP/1.1 200 OK
...
Content-Type: application/xml
Content-Length: nnn
 
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:authority-ref-doc-list xmlns:ns2="http://collectionspace.org/services/common/authorityref">
  <authority-ref-doc-item>
    <docType>Intake</docType>
    <docId>d38d5652-5e51-4a15-9ab9</docId>
    <docNumber>IN2011.1</docNumber>
    <sourceField>intakes_common:depositor</sourceField>
    <value>urn:cspace:core.collectionspace.org:personauthorities:name(person):item:name(JaneDoe1705026588599)'Jane Doe'</value>
    <uri>/intakes/d38d5652-5e51-4a15-9ab9</uri>
  </authority-ref-doc-item>
  ...
</ns2:authority-ref-doc-list>

In the above example, the 'depositor' field of the specified Intake resource has been identified as containing the item of interest (from a specified Person Authority). Since any type of object or procedure could be returned, the listed information fields are abstract. The document ID is the internal CSID. The docNumber is drawn from a field configured in the tenant bindings to be a "number" field. A "name" field can also be configured. The source field in the referring record is indicated, as well as the value of that field. The value can be used to determine the exact term on that was used on the record, in the case that the given authority item contains multiple terms (synonyms).

If a record has multiple references to a given authority item, multiple entries for that referring record will be returned.

An additional query/filter parameter may be specified: "type". This specifies one of a set of configured "classes" of document types to return. In the default configuration, there are types defined "object", "procedure", "authority", etc. If no type is specified, it will default to "procedure."

GET /cspace-services/personauthorities/urn:cspace:name(person)/items/{csid}/refObjs?type=procedure HTTP/1.1

If no related authority references are found in the record, a response with a "200 OK" HTTP status code, containing an empty list - a list with only a root element, but no child elements - is returned.

If an error occurred, some non-2xx code will be returned. Check the HTTP Status Code that is returned in the response's HTTP headers for the specific error.

Read workflow state of an object/procedure/record instance

Retrieves and returns the workflow state of an individual object or procedural record.

Calling method and Arguments

A call to retrieve the workflow state is invoked as an HTTP GET method on an individual object/procedure/record instance, specified by its CollectionSpace ID (CSID), and followed by the "workflow" path component. Standard authentication applies, and user must have read privileges for workflow state.

GET /cspace-services/collectionobjects/{csid}/workflow HTTP/1.1

On success, a response with a "200 OK" HTTP status code is returned, with a payload similar to the following example:

HTTP/1.1 200 OK
...
Content-Type: application/xml
Content-Length: nnn
 
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<document name="workflows">
  <ns2:workflow_common xmlns:ns2="http://collectionspace.org/services/workflow"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     <lifeCyclePolicy>default</lifeCyclePolicy>
     <currentLifeCycleState>deleted</currentLifeCycleState>
  </ns2:workflow_common>
</document>

If an error occurred, some non-2xx code will be returned. Check the HTTP Status Code that is returned in the response's HTTP headers for the specific error.

Update workflow state of an object/procedure/record instance

Updates the workflow state of an individual object or procedural record.

Versions 2.3 and later

In versions 2.3 and later, any particular type of record may have a specific set of workflow states and associated transitions to those workflow states (described collectively as a "lifecycle"). Currently:

• Most records in CollectionSpace have a default set of workflow states and transitions.
• Location/Movement/Inventory records have a similar, 'locking' set of workflow states and transitions, that also includes a "lock" transition to a "locked" state. Records in a locked state can't be edited, or (generally) have their workflow state further changed, making it feasible to "hard save" selected records for auditing purposes.

You can find the workflow states and state transitions available for records that use either the default ("cs_default") or 'locking' ("cs_locking") lifecycles in this file.

Calling method and Arguments

A call to update the workflow state is invoked as an HTTP PUT method on an individual object/procedure/record instance, specified by its CollectionSpace ID (CSID), followed by the "workflow" path component and a path component for a specific transition to a different workflow state. Standard authentication applies, and user must have Update privileges for the type of transition being requested. No payload is sent in the body of this PUT request.

An example of an Update request to the CollectionObject service, to update the workflow state of the CollectionObject record whose CollectionSpace ID (CSID) is 850161ed-466c-4af2-bc45 to the workflow state of deleted, follows below. See each individual service's API documentation for further details:

PUT /cspace-services/collectionobjects/850161ed-466c-4af2-bc45/workflow/delete HTTP/1.1

On success, a response with a "200 OK" HTTP status code is returned, with a payload similar to the following example:

HTTP/1.1 200 OK
...
Content-Type: application/xml
Content-Length: nnn
 
 
<document name="workflow">
    <ns2:workflow_common xmlns:ns2="http://collectionspace.org/services/workflow" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <lifeCyclePolicy>cs_default</lifeCyclePolicy>
    <currentLifeCycleState>deleted</currentLifeCycleState>
</ns2:workflow_common>
</document>

An example of an Update request to the CollectionObject service, to update the workflow state of the CollectionObject record whose CollectionSpace ID (CSID) is 850161ed-466c-4af2-bc45 to the workflow state of project (i.e. active), follows below. See each individual service's API documentation for further details:

PUT /cspace-services/collectionobjects/850161ed-466c-4af2-bc45/workflow/undelete HTTP/1.1

On success, a response with a "200 OK" HTTP status code is returned, with a payload similar to the following example:

HTTP/1.1 200 OK
...
Content-Type: application/xml
Content-Length: nnn
 
 
<document name="workflow">
    <ns2:workflow_common xmlns:ns2="http://collectionspace.org/services/workflow" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <lifeCyclePolicy>cs_default</lifeCyclePolicy>
    <currentLifeCycleState>project</currentLifeCycleState>
</ns2:workflow_common>
</document>

An example of an Update request to the Movement service, to update the workflow state of the Location/Movement/Inventory record whose CollectionSpace ID (CSID) is ea90563a-9b34-4347-a3ab to the workflow state of locked ("hard saved"), follows below.

PUT /cspace-services/movements/ea90563a-9b34-4347-a3ab/workflow/lock HTTP/1.1

HTTP/1.1 200 OK
...
Content-Type: application/xml
Content-Length: nnn
 
 
<document name="workflow">
    <ns2:workflow_common xmlns:ns2="http://collectionspace.org/services/workflow" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <lifeCyclePolicy>cs_locking</lifeCyclePolicy>
    <currentLifeCycleState>locked</currentLifeCycleState>
</ns2:workflow_common>
</document>

If an error occurred, some non-2xx code will be returned. Check the HTTP Status Code that is returned in the response's HTTP headers for the specific error.

Versions 2.2 and earlier

In versions 2.2 and earlier, the only meaningful workflow states to which you can update (or "transition") a record in CollectionSpace are:

• project This represents an active record, and is the default workflow state for a newly-created record.
• deleted This represents a "soft deleted" record; i.e. a record that has been marked for deletion. The record and all of its data still exist within the CollectionSpace system, although the record may not be returned via some GET requests. (See Common Services REST API documentation#Filtering on workflow state for details.) The record can be "undeleted" by having its workflow state updated back to the project state.

Other workflow states may be added in future releases.

Calling method and Arguments

A call to update the workflow state is invoked as an HTTP PUT method on an individual object/procedure/record instance, specified by its CollectionSpace ID (CSID), and followed by the "workflow" path component. Standard authentication applies, and user must have update privileges for workflow state.

You can update a record to a different workflow state by specifying that state in the <currentLifeCycleState> element in the payload of your UPDATE request.

An example of an Update request to the CollectionObject service, to update the workflow state of the record whose CollectionSpace ID (CSID) is 850161ed-466c-4af2-bc45 to the workflow state of deleted, follows below. See each individual service's API documentation for further details:

PUT /cspace-services/collectionobjects/850161ed-466c-4af2-bc45/workflow HTTP/1.1
Content-type: application/xml
Content-Length: nnn
 
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<document name="workflows">
  <ns2:workflow_common xmlns:ns2="http://collectionspace.org/services/workflow">
     <lifeCyclePolicy>default</lifeCyclePolicy>
     <currentLifeCycleState>deleted</currentLifeCycleState>
  </ns2:workflow_common>
</document>

On success, a response with a "200 OK" HTTP status code is returned, with a payload similar to the following example:

HTTP/1.1 200 OK
...
Content-Type: application/xml
Content-Length: nnn
 
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<document name="workflows">
  <ns2:workflow_common xmlns:ns2="http://collectionspace.org/services/workflow"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     <lifeCyclePolicy>default</lifeCyclePolicy>
     <currentLifeCycleState>deleted</currentLifeCycleState>
  </ns2:workflow_common>
</document>

If an error occurred, some non-2xx code will be returned. Check the HTTP Status Code that is returned in the response's HTTP headers for the specific error.

List related records

List related records via the Relations service

For a rich set of REST API calls to return related records via the Relations service, please see Relationship Service RESTful APIs.

These calls all return lists of Relation records, the "linking" records that relate any two other types of records.

List related records via rtSbj and rtObj

To list records of a specific type that are related to a particular record, specified by its CollectionSpace ID (CSID), add the rtSbj or rtObj query parameter to the call.

For example, to list Movement records related to the record (which can be of nearly any type) specified by CSID 850161ed-466c-4af2-bc45, where that specified record is the subject of the relationship:

GET /cspace-services/movements?rtSbj=850161ed-466c-4af2-bc45 HTTP/1.1

Similarly, to list Movement records related to the record specified by CSID 850161ed-466c-4af2-bc45, where that record is the object of the relationship:

GET /cspace-services/movements?rtObj=850161ed-466c-4af2-bc45 HTTP/1.1

Both of the above requests return lists of Movement records.