/
Common Services REST API documentation

Common Services REST API documentation

Jun 07, 2019

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.
On This Page

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==