Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- docuteam:bridge [2019/06/11 12:02] – andi
+++ docuteam:bridge [2023/02/06 14:33] (aktuell) – gelöscht Administrator
@@ Zeile 1: / Zeile 1: @@
-====== docuteam bridge v1.0 ======
-==== Goal ====
-Clients – mostly client applications, but also individuals – should be able to submit a deposition (data and metadata) to our ingest plattform. Depositions will be picked up by docuteam feeder workflows, usually processing and eventually storing the information in a repository. After a successful ingest, feeder (and subsequently bridge) return PIDs for every object (file, folder) within the deposition. Using these PIDs, the client will be able to access (read and change) the deposited objects.
-{{:docuteam:bridge_v1.png?400|}}
-==== Key points ====
-  * Bridge is a set of rest APIs that respond in JSON (and binary data)
-  * Bridge is agnostic to package format
-    * Use the simple, bagit-based format docuteam dublin core 1.0 (see Appendix A)
-    * Use Matterhorn METS (see [[https://wiki.docuteam.ch/lib/exe/fetch.php?media=oais:spezifikation_matterhorn-mets_20160830_wi.pdf|Specification]])
-    * Use other formats, e.g. eCH-0160, SEDA
-  * Bridge is composed of 3 APIs:
-    * **depositions:** deposition of new packages
-    * **access:** read data from the repository
-    * **changes:** update or purge objects in the repository
-==== Introduction to the APIs ====
-For security reasons, bridge uses only https. Access is restricted via tokens that must be transmitted with each request via the “token” parameter (regardless the HTTP method: get, post, put, patch, delete). Roles are associated to tokens and limit their scope of operation.
-  * Depositions
-    * use internal IDs
-    * upon success, the PIDs, which are the repository’s persistent IDs and different from bridge internal IDs, are made available via the feeder response field for the whole tree of the deposited objects
-  * Changes must imperatively target (for update or purge) one single object in the repository identified by a PID. They can be limited to:
-    * metadata (data is unchanged, only for updates)
-    * data (metadata is unchanged)
-    * object (metadata+data)
-  * Access
-    * is a proxy to docuteam rservices
-===== 1 - Authentication =====
-  * An authentication token must be at least 15 characters long.
-  * Tokens are passed as the “token” HTTP parameter, for example when using GET, which results in urls of the form: http://server/access/sync_original/:pid?token=123456789012345
-==== Roles ====
-There are 5 roles:
-  * The 3 first roles are limited to the organization they are bound to:
-    * read (is limited to access api)
-    * create (same as read, can also list and create depositions via the deposition API)
-    * manage (same as create, can in addition update or delete repository objects via the nodes API)
-  * The 2 last roles are not limited to any organization
-    * admin (authentication i.e. token administration via the GUI)
-    * feeder (super user, can do anything, including all deposition status updates)
-Recommendation:
-  * use only one token with read roles in applications that do not create nor update depositions,
-  * use only one token with create role in application that create depositions but do not use the changes api,
-  * use only one token with manage role in applications that use the changes api.
-===== Documentation =====
-The documentation of docuteam bridge {{ :docuteam:bridge_api_-_v1_20190312.pdf | can be downloaded in PDF-format.}}