Features
With PLAS, a service is built against one shared standard instead of one integration per library system. The features show what patrons and staff can do in your service, and which calls in the API carry it.
55 supported · 44 not yet · 32 groupsThree areas
The features follow the shape of a library service: finding material, the patron's own account, and what the library offers beyond the collection.
- 12 of 34 supported
Search and discovery
Let patrons search, find a work and browse the collection. The calls are in the Provider API, and search also exists as the Search API — a subset with its own specification that can, for example, be handed to a third party.
Open the area - 41 of 52 supported
The patron
Everything that belongs to the patron's own relationship with the library — from logging in to paying a fee. The calls are in the Provider API; for single sign-on and events they also go the other way, through the Vendor API the service implements itself.
Open the area - 2 of 13 supported
Library and content
What the library offers beyond the collection: its events, its people and information about the library itself. The events are in the Provider API and in the Content API — a subset with its own specification.
Open the area
Where to start
Four common starting points, each a handful of features that carry a first version of a service.
-
A patron app
Log in, see loans and renew them, reserve material and follow the queue.
-
Search and discovery
Search with suggestions and filters, and show a work with its editions and availability.
-
Check in and out
Check material out and in at a self-service machine or the staff desk, and let patrons pay outstanding fees.
-
The library's events
Show what is happening at the library, and let patrons browse it.
How to read a feature
Every feature has a purpose: one sentence on what it does for the patron or for staff. A supported feature also has up to four parts, always in the same order — what you can build (for whoever decides), a typical flow as a pattern you can reuse, what the API provides in rules, fields and states, and the calls in the API, each linking to the reference.
Supported and not yet
- Supported
The feature list says yes, and the calls are in the specification in production. They are listed with the feature.
- Not yet
The feature is in the PLAS feature list but not marked as supported — or its calls are not in the specification in production. It is described so you can see how it fits with the rest.
PLAS grows gradually, guided by the needs of libraries and vendors rather than a fixed timeline. The feature list is maintained by the PLAS team, and a feature that becomes supported is listed under New features in the changelog, at the version where its calls arrived. See the changelog
How the calls are shown
Some features are one call. Most are several, and the shape of the list tells you how they fit together.
-
Sequence
The calls are made in this order, each building on the one before.
For example: Reserve material -
Composition
Several calls build one view. The first is the main call; the others add to it.
For example: Search -
Alternatives
The feature can be built in more than one way — for example with a password or with single sign-on. Choose one.
For example: Log in -
Data only
The API supplies the data, and your service performs the action — for example drawing a map.
For example: Find material, map
Some features can be switched on or off by the library system. Get — and for search and content Get and Get — tells your service which ones are available, and a feature that depends on it says so.