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 2593662710 of this API are described first, followed by the common features of the 2593662710.
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
pgSzis 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).pgSzhas a maximum value of 1000 (should probably support configuration of this as well).Setting
pgSz=0will return up to the maximum number of items, on a single page. (When large numbers of items will be returned, the response to apgSz=0request may be somewhat slow.)
pgNum indicates the page number to return. This leverages the
pgSzvalue to produce the starting offset for the returned results.If
pgNumis 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.
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 #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:myCustomFieldThe 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+DESCTo sort on more than one field, separate each sort field with ,+. Example:
?sortBy=movements_common:locationDate+DESC,+movements_common:movementNoteRecords 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:
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 #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.
#Partial Term Matching for object/procedure/record instances
Related Authority References for (aka Terms Used by) object/procedure/record instances
#Update workflow state of an object/procedure/record instance
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.1Most read service calls accept a single, optional query parameter:
GET /cspace-services/collectionobjects/{csid}?wf_deleted=false HTTP/1.1If 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 #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 #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.1Delete 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.1As 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.1On 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.
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.
Verify whether this assertion is currently accurate for keyword 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.
Keyword searches:
Verify all of the following with Richard. Explain further (e.g. "short words") where needed. Identify whether values in repeatable fields can be searched, either as repeatable single scalar fields, or with either or both of the upcoming services paradigms for implementing repeatable groups of fields. Identify any significant database system-specific differences, such as between PostgreSQL and MySQL.
Are conducted within the full text of all fields.
Are case-insensitive.
When multiple keywords are provided, are carried out as though a Boolean OR is present between each keyword.
Will not match a database-dependent list of stopwords. (See, for example, Issue CSPACE-807.)
Will not match short words.
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.1To search on multiple keywords, add a plus sign ("+") between each keyword:
GET /cspace-services/collectionobjects?kw=whetstone+sharpening+sharpen HTTP/1.1Query 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.
Add example below. Verify and describe the interaction between pagination and search.
HTTP/1.1 200 OK
...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.