Common Services REST API documentation
REST-based API
All of CollectionSpace's exposed services offer a REST-based Application Programming Interface (API). This API allows you to perform CRUD+L operations (create, read, update, and delete of individual resources, plus list operations such as list all, keyword search, and partial term matching) on a variety of entities that represent a museum's or related institution's collections, such as collection objects, acquisitions, and loans. You can also use this same API to manage a number of the internal entities within a CollectionSpace system, such as user accounts.
There are some minor variations in this API from service to service. However, nearly all services accept requests and provide responses in nearly exactly the same way. The API functionality that is common across all the services is documented here. For details of the REST APIs for individual services, please see Services Layer REST API.
The general principles of this API are described first, followed by the common features of the CRUD+L operations.
General principles
Item-level CRUD and List operations
Most services support both item-level CRUD operations and List operations (hence "CRUD+L"):
- The item-level CRUD operations allow you to create, read, update and delete individual resources. Most services use a uniform schema to describe these resources, which is used in both create and update requests, and in the responses returned from read requests. This schema is divided into several parts, following the principles articulated in the CollectionSpace Services Architecture. (A small number of services return a schema consisting only of a single part.)
- The list operations return lists of multiple resources. The list operations of most services use a second, uniform schema, which returns minimal, summary information about each item, together with identifiers that can be used to individually retrieve more detailed information about any item. The type of data returned for each item is generally independent of the type of list function (e.g. list all, query, term suggestion) for a given service. There are plans to support mechanisms to request that additional fields be added to the returned results, but this functionality is not yet supported. Most services support pagination of list results. See details below, and in individual service API documentation.
Invoking the REST APIs
All services are invoked with HTTP requests:
- HTTP POST requests are used to create resources.
- HTTP GET requests are used to read resources. They are also used in list operations that may return multiple items, such as list all, keyword search and partial term matching (term suggestion / term completion).
- HTTP PUT requests are used to update (change) resources.
- HTTP DELETE requests are used to delete resources.
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.
Suggested addition
Add: "Payload parts are denoted by the prefix 'ns2:' (for example, <ns2:intakes_common></ns2:intakes_common>)"? Is this prefix used consistently throughout the service payloads?
- 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).
Tenant name in URN; other changes?
Note that the urn now includes a segment that indicates the tenant, as in this example:
urn:cspace:core.collectionspace.org:vocabularies:name(conditionfitness):item:name(unsuitable)'Unsuitable'
('core' is the tenant in this example.)
Has anything else changed?
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 apgSz=0
request may be somewhat slow.)
- If
- 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 viapgNum=1
, and so on.
- If
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.
Records will be ordered by the collation (ordering) behavior of your database system. This may, in turn, be based on collation and language settings for your database, your operating system, or both. Collectively, these settings may determine whether (in the Roman alphabet, for instance) uppercase and lowercase characters (like "A" and "a") are ordered together or separately; how characters with diacritical marks are ordered, relative to similar characters without those marks; and how punctuation and other special characters are handled when ordering. By adjusting those settings, you may also be able to adjust how records in CollectionSpace are ordered, when you use the ?sortBy=
query parameter.
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.
There have been discussions about different profilesof information that would be defined (probably in configuration) and specified as query parameter to the List operation. In addition, we may support a facility to include extra, specific fields (from any of the common, domain, or local schema parts) for each instance in the list-results information returned. Once this functionality has been resolved, it will be documented here.
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
QuebecCanada
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" high, 6" wide, projects 10" (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:
Error (Status Code) | Meaning | Returned When |
---|---|---|
400 | Bad Request | The resource could not be created because the data sent in the entity body of the request was bad, as determined by the service. |
401 | Unauthorized | The resource could not be created because the client submitting the request either has not provided authentication credentials, or authentication failed (e.g. due to an invalid username or password) after such credentials were provided. |
403 | Forbidden | The resource could not be created because the client submitting the request was not authorized to create new resources in this container. |
409 | Conflict | The resource could not be created because the submitted data would create a duplicate (non-unique) resource, as determined by the service. |
500 | Internal Server Error | A service error prevented the resource from being created. |
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" high, 6" wide, projects 10" (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:
Error (Status Code) | Meaning | Returned When |
---|---|---|
401 | Unauthorized | The resource could not be read (i.e. returned) because the client submitting the request either has not provided authentication credentials, or authentication failed (e.g. due to an invalid username or password) after such credentials were provided. |
403 | Forbidden | The resource could not be read because the client submitting the request was not authorized to read it. |
404 | Not Found | The resource requested for reading does not exist. (When the |
500 | Internal Server Error | A service error prevented the resource from being read. |
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" high, 6" wide, projects 10" (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:
Error (Status Code) | Meaning | Returned When |
---|---|---|
400 | Bad Request | The resource could not be updated because the data sent in the entity body of the request was bad, as determined by the service. |
401 | Unauthorized | The resource could not be updated because the client submitting the request either has not provided authentication credentials, or authentication failed (e.g. due to an invalid username or password) after such credentials were provided. |
403 | Forbidden | The resource could not be updated because the client submitting the request was not authorized to update resources in this container. |
404 | Not Found | The resource requested for updating does not exist. |
500 | Internal Server Error | A service error prevented the resource from being updated. |
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.
This is a "hard" delete, which removes the record and all of its data from the CollectionSpace system. Unless an export or backup has previously been performed, the record and its data can be considered permanently deleted and unrecoverable.
To perform a "soft" delete, which simply marks a record for deletion, while retaining the record and its data, see Common Services REST API documentation#Update workflow state of an object/procedure/record instance.
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:
Error (Status Code) | Meaning | Returned When |
---|---|---|
401 | Unauthorized | The resource could not be deleted because the client submitting the request either has not provided authentication credentials, or authentication failed (e.g. due to an invalid username or password) after such credentials were provided. |
403 | Forbidden | The resource could not be deleted because the client submitting the request was not authorized to delete it. |
404 | Not Found | The resource requested for deletion does not exist. |
500 | Internal Server Error | A service error prevented the resource from being deleted. |
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.
Error (Status Code) | Meaning | Returned When |
---|---|---|
401 | Unauthorized | The list of resources could not be read (i.e. returned) because the client submitting the request either has not provided authentication credentials, or authentication failed (e.g. due to an invalid username or password) after such credentials were provided. |
403 | Forbidden | The list of resources could not be read because the client submitting the request was not authorized to read it. |
404 | Not Found | The list of resources requested for reading does not exist. This may occur, for example, if a path element in the request URL is incorrect. Note that if a list of resources does exist, but currently contains zero items, a success response with a "200 OK" HTTP status code will be returned, containing an empty list - a list with only a root element, but no child elements. |
500 | Internal Server Error | A service error prevented the list of resources from being read. |
Keyword Search for object/procedure/record instances
This section is in process and is currently incomplete. Remaining to-do items:
- verify that read privileges affect results as described
- identify any significant database system-specific differences, such as between PostgreSQL and MySQL. The details below are all correct for the database setup used for https://core.dev.collectionspace.org/cspace-services as of 2022-02-01
- provide info on what the stopwords are (or how to find that list)
- Verify and describe the interaction between pagination and search in returned result examples (though this seems like it could be handled in a more general section, since an abstract-common-list is returned)
- Add error responses
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
Query parameters may follow the previous path component of the URL, either with or without a trailing slash: .../collectionobjects/?kw=
keyword
and .../collectionobjects?kw=
keyword
are both accepted as valid requests.
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.
Need to add error responses here.
Advanced Search for object/procedure/record instances
This section is in process and is currently incomplete.
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.
Verify whether this assertion is currently accurate for advanced search.
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.
Query parameters may follow the previous path component of the URL, with or without a trailing slash: .../collectionobjects/?as=
search_expression
and .../collectionobjects?as=
search_expression
are both accepted as valid requests.
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.
Need to add error responses here.
Partial Term Matching for object/procedure/record instances
This section is in process and is currently incomplete.
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.
Verify whether this assertion is currently accurate for partial term matching.
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:
Add example below. Verify and describe the interaction between pagination and search.
Mention and provide example(s) of the use of anchors and wildcards in partial term matching requests. For a look at how these features work, conceptually, please see /wiki/spaces/collectionspace/pages/666274082.
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.
Error (Status Code) | Meaning | Returned When |
---|---|---|
401 | Unauthorized | The list of resources could not be read (i.e. returned) because the client submitting the request either has not provided authentication credentials, or authentication failed (e.g. due to an invalid username or password) after such credentials were provided. |
403 | Forbidden | The list of resources could not be read because the client submitting the request was not authorized to read it. |
404 | Not Found | The list of resources does not exist. This may occur, for example, if a path element in the request URL is incorrect. Note that if a list of resources does exist, but currently contains zero items that are matched by the partial term, a success response with a "200 OK" HTTP status code will be returned, containing an empty list - a list with only a root element, but no child elements. |
500 | Internal Server Error | A service error prevented the list of resources from being read. |
Term Status Filtering for Authority terms
This section is in process and is currently incomplete.
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.
Error (Status Code) | Meaning | Returned When |
---|---|---|
401 | Unauthorized | The list of resources could not be read (i.e. returned) because the client submitting the request either has not provided authentication credentials, or authentication failed (e.g. due to an invalid username or password) after such credentials were provided. |
403 | Forbidden | The list of resources could not be read because the client submitting the request was not authorized to read it. |
404 | Not Found | The list of resources does not exist. This may occur, for example, if a path element in the request URL is incorrect. Note that if a list of resources does exist, but currently contains zero items that are matched by the partial term, a success response with a "200 OK" HTTP status code will be returned, containing an empty list - a list with only a root element, but no child elements. |
500 | Internal Server Error | A service error prevented the list of resources from being read. |
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.
Verify whether this assertion is currently accurate for related authority references.
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.
Error (Status Code) | Meaning | Returned When |
---|---|---|
401 | Unauthorized | The list of authority references could not be read (i.e. returned) because the client submitting the request either has not provided authentication credentials, or authentication failed (e.g. due to an invalid username or password) after such credentials were provided. |
403 | Forbidden | The list of authority references could not be read because the client submitting the request was not authorized to read the relevant resource. |
404 | Not Found | The resource from which a list of authority references was requested does not exist. Note that if the resource does exist, but currently contains no authority references, a success response with a "200 OK" HTTP status code will be returned, containing an empty list - a list with only a root element, but no child elements. |
500 | Internal Server Error | A service error prevented the list of authority references, or the relevant resource from which that list was requested, from being read. |
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.
Verify whether this assertion is currently accurate for related object references (probably not).
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.
Error (Status Code) | Meaning | Returned When |
---|---|---|
401 | Unauthorized | The list of references could not be read (i.e. returned) because the client submitting the request either has not provided authentication credentials, or authentication failed (e.g. due to an invalid username or password) after such credentials were provided. |
403 | Forbidden | The list of references could not be read because the client submitting the request was not authorized to read the relevant resource. |
404 | Not Found | The resource from which a list of references was requested does not exist. Note that if the resource does exist, but currently contains no references to the item, a success response with a "200 OK" HTTP status code will be returned, containing an empty list - a list with only a root element, but no child elements. |
500 | Internal Server Error | A service error prevented the list of references, or the relevant resource from which that list was requested, from being read. |
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.
Error (Status Code) | Meaning | Returned When |
---|---|---|
400 | Bad Request | The workflow state could not be updated because the data sent in the entity body of the request was bad, as determined by the service. |
401 | Unauthorized | The workflow state could not be read (i.e. returned) because the client submitting the request either has not provided authentication credentials, or authentication failed (e.g. due to an invalid username or password) after such credentials were provided. |
403 | Forbidden | The workflow state could not be read because the client submitting the request was not authorized to read the relevant resource. |
404 | Not Found | The resource from which the workflow state was requested does not exist. |
500 | Internal Server Error | A service error prevented the workflow state from being read. |
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.
Error (Status Code) | Meaning | Returned When |
---|---|---|
401 | Unauthorized | The workflow state could not be updated because the client submitting the request either has not provided authentication credentials, or authentication failed (e.g. due to an invalid username or password) after such credentials were provided. |
403 | Forbidden | The workflow state could not be updated because the client submitting the request was not authorized to update that state. |
404 | Not Found | The resource on which a workflow state update was requested does not exist. |
500 | Internal Server Error | A service error prevented the workflow state from being updated. |
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 theproject
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.
Error (Status Code) | Meaning | Returned When |
---|---|---|
400 | Bad Request | The workflow state could not be updated because the data sent in the entity body of the request was bad, as determined by the service. |
401 | Unauthorized | The workflow state could not be updated because the client submitting the request either has not provided authentication credentials, or authentication failed (e.g. due to an invalid username or password) after such credentials were provided. |
403 | Forbidden | The workflow state could not be updated because the client submitting the request was not authorized to update that state. |
404 | Not Found | The resource on which a workflow state update was requested does not exist. |
500 | Internal Server Error | A service error prevented the workflow state from being updated. |
List related records
This section is an early placeholder; it needs considerable expansion and refinement.
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.