Skip to content

PR #564 finetuning of back-end "availability" terminology #565

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
m-mohr merged 1 commit into from
Jul 1, 2025
Merged

PR #564 finetuning of back-end "availability" terminology #565

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 8 additions & 6 deletions extensions/federation/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -108,8 +108,10 @@ schema:

## Resources supported only by a subset of back-ends

Every discoverable resource that is defined as an object and allows to contain additional properties, can list the subset of back-ends that permanently support or host the exposed resource/functionality.
Examples of where this could apply to (**not** comprehensive):
Discoverable resources can explicitly list the subset of back-ends that support or host the exposed resource or functionality with the property `federation:backends`.

Schema-wise, this only applies to resources that are defined as an object and allow to contain additional properties.
For example (**not** comprehensive):

- `GET /collections`
- `GET /collections/{id}`
Expand Down Expand Up @@ -198,9 +200,9 @@ This also covers the case where the federation supports splitting a process into
## Temporarily or unintentionally unavailable resources

Resources and back-ends can be temporarily or unintentionally unavailable.
It is especially important to communicate to users missing resources when compiling lists of resources across multiple back-ends.
Clients will assume that all lists of resources are the a combination of all back-ends listed under`federation` in `GET /`.
Federated APIs can expose if any of the back-ends is temporarily not available and thus is not part of the response.
It is especially important to communicate to users missing resources when compiling a **list of resources** across multiple back-ends.
Clients will assume that all lists of resources are a combination of all back-ends listed under `federation` in `GET /`.
Federated APIs can expose if any of the back-ends was not available when building the resource listing response with the property `federation:missing`.

Examples of where this could apply to (**not** comprehensive):

Expand All @@ -223,7 +225,7 @@ schema:
properties:
'federation:missing':
description: >-
Lists all back-ends that were temporarily not considered in the response (e.g. because they were not accessible).
Lists all back-ends that were unexpectedly unavailable during compilation of the response.
If not given or empty, all back-ends supporting this endpoint were considered for creating the response.
Back-ends that are listed as offline in the capabilities still need to be listed here.
type: array
Expand Down