Comment on page
This specification defines a RESTful API over HTTPS for the [Catalog Protocol].
<base>notation indicates the base URL for a catalog service endpoint. For example, if the base catalog URL is
api.example.com, the URL
https://<base>/catalog/requestwill map to
- 2.All request and response messages must use the
filterproperty is optional. If present, the
filterproperty can contain an implementation-specific filter expression or query to be executed as part of the catalog request.
A catalog service may require authorization. If the catalog service requires authorization, requests must include an HTTP
Authorizationheader with a token. The semantics of such tokens are not part of this specification.
- Versioning will be done via URLs. TBD.
A catalog service may paginate the results of a
CatalogRequestMessage. Pagination data is specified using Web Linking and the HTTP
Linkheader will contain URLs for navigating to previous and subsequent results. The following request sequence demonstrates pagination:
Link: <https://provider.com/catalog?page=2&per_page=100>; rel="next"
Second page response:
Link: <https://provider.com/catalog?page=1&per_page=100>; rel="previous"
Link: <https://provider.com/catalog?page=3&per_page=100>; rel="next"
Last page response:
Link: <https://provider.com/catalog?page=2&per_page=100>; rel="previous"
When an implementation supports protected datasets, it may offer a proof metadata endpoint clients can use to determine proof requirements. If the implementation offers a proof data endpoint, it must use the
dspace-trustWell-Known Uniform Resource Identifier at the top of the path hierarchy:
The contents of the response is a JSON object defined by individual trust specifications and not defined here.
Note that if multiple connectors are hosted under the same base URL, a path segment appended to the base well-known URL can be used, for example,
Last modified 3d ago