Date: Fri, 29 Mar 2024 02:36:48 -0400 (EDT) Message-ID: <1020114015.29888.1711694208834@lyrasis1-roc-mp1> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_29887_2098870027.1711694208833" ------=_Part_29887_2098870027.1711694208833 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Fedora 4 authorization is designed to be fine grained, while at the same= time manageable by administrators and end users. Authentication is managed= by the servlet container or externally, but authorization mechanisms are o= pen to extension and many reference implementations are included. Roles-bas= ed access control is an included feature that makes permissions more manage= able and at the same time easier for external applications to retrieve, ind= ex and enforce. Finer grained security checks have no
The Fedora 4 Backup capability allows a user, such as the repository man= ager, make a REST call to have the repository binaries and metadata exporte= d to the local file system. Inversely, the Restore capability allows a user= to make a REST call to have the repository restored from the contents of a= previous Backup operation.
To support the differing needs for sophisticated, rich searching, Fedora= 4 comes with a standard mechanism and integration point for indexing conte= nt in an external service. This could be a general search service suc= h as Apache Solr or a standalone triplestore such as Sesame or Fuseki.
RDF support is a core feature of Fedora 4, used as the primary data form= at for the REST API. A triplestore is not bundled into the repository= itself. Instead, Fedora 4 sends events when the repository is update= d, and the Indexer copies RDF from the repository to an external triplestor= e to keep it in sync with the repository. This pattern, which is also= used for search functionality for the same reasons, allows maximum flexibi= lity about what triplestore to use, and removes the overhead of keep
Fedora 4 has the ability to expose external content, as if it were a par= t of the repository. Federation may be useful for migrating content i= nto Fedora 4 or serving large files already on disk.
The Fedora 4 HTTP API is generally a RESTful API. HTTP methods like GET,= PUT, POST and DELETE are implemented on most resource paths. The API also = relies heavily on content negotiation to deliver context-appropriate respon= ses, and a HATEOAS-driven text/html response (providing a decent GUI experi= ence on top of the repository).
Fedora 4 supports the ability to wrap multiple REST API calls into a sin= gle transaction that can be committed or rolled back as an atomic operation= .
Within Fedora 4, snapshots of the current state of a resource may be sav= ed into the version history. The RDF for historic version shapshots m= ay be browsed and old non-RDF content may be downloaded. Furthermore,= an object or subgraph may be reverted to the state that it existed in a hi= storic version.
To support horizontal scalability use cases as well as geographic distri= bution, Fedora 4 can be configured as a cluster of application servers.
Identifiers can be specified in REST API calls and generated either auto= matically using the internal PID minter or via an external REST service.