Sooner or later, developers will have to deal with (long) lists of items. For example, a set of blog posts, activities or users. These lists often need to be paginated, sorted, and filtered. For dealing with these problems, we have Atomic Collections.
An Atomic Collection is a Resource that links to a set of resources.
Note that Collections are designed to be dynamic resources, often (partially) generated at runtime.
Collections are Endpoints, which means that part of their properties are calculated server-side.
Collections have various filters (
value) that can help to build a useful query.
members: How many items (members) are visible per page.
property: Filter results by a property URL.
value: Filter results by a Value. Combined with
property, you can create powerful queries.
sort_by: A property URL by which to sort. Defaults to the
sort_desc: Sort descending, instead of ascending. Defaults to
current_page: The number of the current page.
page_size: How many items (members) are visible per page.
total_pages: How many pages there are for the current collection.
total_members: How many items (members) are visible per page.
Persisting Properties vs Query Parameters
Since Atomic Collections are dynamic resources, you can pass query parameters to it. The keys of the query params match the shortnames of the properties of the Collection.
For example, let's take the Properties Collection on atomicdata.dev.
We could limit the page size to 2 by adding the
page_size=2 query parameter:
Or we could sort the list by the description property:
Note that URLs need to be URL encoded.
These properties of Collections can either be set by passing query parameters, or they can be persisted by the Collection creator / editor.