Handling Collections

Many of the DLCS resource properties are links that return a collection of resources. For example, the images in a space:


This collection resource is defined thus:

images (🔗)

domain range readonly writeonly
vocab:Space hydra:Collection True False
Method Label Expects Returns Status
GET Retrieves all Image hydra:Collection 200 OK
POST Creates a new Image vocab:Image vocab:Image 201 Image created, 400 Bad Request

The resource returned from this URL is a Hydra collection.

In some cases, you as the API consumer will supply a collection - you POST a collection of images to your customer queue, e.g., at /customers/34/queue. Here, you would construct a Hydra Collections as the JSON payload of your POST.

Clients of the DLCS API should expect to deal with paged collections in any scenario that returns a collection.

Conversely, the DLCS will not accept a paged collection as input (e.g., as a job sent to the queue), because it might not be able to follow the links to subsequent pages. This is also an encouragement to keep batch sizes small (e.g., 100).

Are the objects that are returned in a collection fully populated?

It depends. We hope the answer to this is “they are when you need them to be” - i.e., when you expect to be able to work with the fields of a resource without having to make further HTTP requests, one per member of the collection. Sometimes the returned collection members will be lightweight, e.g.,


Here you are provided with just the link and the fact that the resource at the other end of the link is a Customer.

RDF note

Although in the JSON-LD serialisation, the Hydra Collection’s “member” property has an inherent ordering, in the underlying RDF model there is no such ordering. This is because “member” is not defined as a @list in JSON-LD terms. This is an open issue with our use of the Hydra model.