API-Vitam - Access version v1
https://api.vitam.gouv.fr/access-external/{version}
- version: required(v1)
Avertissements
Cette version d'API présente des fonctionnalités sous différents statuts :
- Supportées : rien n'est spécifié, la fonctionnalité ou la donnée est supportée
Pour le détail du modèle de chaque collection, se référer à la documentation du modèle de données.
Licence
Ce document est distribué sous les termes de la Licence Ouverte V2.0
API Access
L'API d'Accès propose les points d'entrées et les méthodes pour atteindre, requêter et récupérer les informations depuis les Units et les Objects.
Cette API est globalement reproduite dans tous les autres points d'accès lorsque l'accès à des Units et Objects est nécessaire. Les fonctionnalités offertes peuvent par contre varier (droit en modification, effacement, ...) selon le contexte.
API Access externe
Dans le projet Vitam, Les API externes supportent le POST-X-HTTP-OVERRIDE=GET. Les API internes ne supportent que le GET.
Units api
Units est le point d'entrée pour toutes les descriptions d'archives. Celles-ci contiennent les métadonnées de description et les métadonnées archivistiques (métadonnées de gestion).
Une Unit peut être de 3 types :
- "ingest" (unité archivistique classique),
- "holding" (unité archivistique d'arbre de positionnement)
- "filing" (unité archivistique de plan de classement). Les métadonnées de ces unités peuvent tout aussi bien décrire un dossier qu'un groupe d'objet lié. Les Units peuvent être organisées en arborescence et peuvent posséder :
- Plusieurs racines dans l'arborescence (Unit de plus haut niveau)
- Plusieurs parents directs (un dossier peut être rattaché à plusieurs dossiers)
Il s'agit d'une représentation dite de "graphe dirigé sans cycle" (DAG en Anglais pour "Directed Acyclic Graph").
Pour le model SEDA, il est équivalent à l'ArchiveUnit, notamment pour les parties Content et Management. Pour l'Isad(G) / EAD, il est équivalent à Description Unit.
Au plus, un seul groupe d'objets d'archives (Objects) est attaché à une Unit. Cela signifie que si une Unit doit avoir plus d'un groupe d'objets d'archive attaché, vous devez spécifier des sous-Units à l'Unit principale, chaque sous-Unit n'ayant qu'un groupe d'objets d'archives attaché. Un même groupe d'objets d'archives peut par contre être attaché à de multiples Units.
Aucun effacement n'est autorisé, ni aucune mise à jour complète (seules les mises à jours partielles sont autorisées via la commande POST via un update de masse). Les mises à jour des Unit doivent être réalisées via des mises à jour en masse, l'API d'update unitaire étant dépréciée.
Structuration des métadonnées
La structuration d'un Unit est la suivante :
{
"#id": "UnitId",
"#tenant": "tenantId",
"#version": 1,
"#unitType" : "HOLDING_UNIT (arbre), FILING_UNIT (Plan) ou INGEST (ArchiveUnit standard)"
//Métadonnées du content
"DescriptionLevel": "Fonds",
"Title": "titre",
"Description": "description du Unit",
"#Management": {
"StorageRule": {},
"AppraisalRule": {},
"AccessRule": {},
"DisseminationRule": {},
"ReuseRule": {},
"ClassificationRule": {},
"HoldRule": {},
"NeedAuthorization": false // Accès nécessitant une autorisation explicite
},
"#unitups": [ "unitParentId", "unitParentId"], // liste des parents immédiats
"#min": 1,
"#max": 1,
"#object": "objectId",
"#nbunits": 1, // Nombre de Unit fils
"#operations" : [ "id", "id" ], // liste des opérations auxquelles cette AU a participées
"#allunitsups": [ "unitParentId", "unitParentId"], // liste de tous les parents jusqu'au sommet
"#storage": { "#nbc": 2 } // information de stockage,
"#originating_agency": "originationAgencyId",
"#originating_agencies": [ "originationAgencyId" ],
"#operations" : [ "operationId" ] // liste des opérations auxquelles cette AU a participées
Objects api
/units/{idu}/objects est le point d'entrée pour la recherche sur les groupes d'objets associés à une unité archivistique dont l'identifiant est passé en paramètre.
/objects est le point d'entrée pour la recherche sur tout les groupes d'objets.
Ces points d'entrée permettent la recherche sur :
- tous les groupes objets, qui contiennent les métadonnées techniques (nom des objets, format, type MIME...)
- tous les objets binaires (des fichiers) non binaires (des références à des objets d'archives physiques ou externes au système).
Un Groupe d'Objects peut posséder de 1 à N objets. Chaque objet a un usage et une version dans son groupe d'objet. Ces distinctions permettent de différencier des usages comme version de conservation, version de diffusion...
Il peut exister plusieurs versions de l'objet pour un même usage (pour l'original numérique notamment), au fur et à mesure du cycle de vie du Groupe d'Objects. Par exemple l'objet d'usage+version "BinaryMaster_1" est la version 1 de l'usage BinaryMaster, le "BinaryMaster_2" est la version 2 de l'usage BinaryMaster. Dans le modèle de données de la solution logicielle Vitam, cet usage correspond au champ "qualifier".
Pour le model SEDA, il est équivalent à un DataObjectGroup. Pour l'EAD, il est équivalent à un Digital Archive Object Group or Set.
Chaque Groupe d'Objets doit être attaché à au moins un parent Unit.
Seul l'accès est autorisé (GET/POST en override de GET).
Chaque Objet n'est lié qu'à un seul Groupe d'objets. Chaque Objet a un qualifier (spécifiable via #qualifiers dans le DSL pour l'accès métadonnées et X-Qualifier en Header pour l'accès aux objets binaires) :
- PhysicalMaster : il s'agit de l'original papier ou physique s'il existe
- BinaryMaster : il s'agit de l'original numérique s'il existe
- Dissemination : il s'agit d'une version adaptée à la diffusion via le réseau et l'usage dans des navigateurs
- Thumbnail : il s'agit d'une version adaptée à la diffusion dans une taille et une qualité correspondant à une vignette (utile lors de l'affichage d'une liste)
- TextContent : il s'agit d'une version ne contenant que le texte du document, sans la mise en forme (son usage est en prévision du futur, par exemple pour des opérations d'analyses sémantiques)
Ces qualifiers peuvent être utilisés dans une requête GET en conjonction avec le Header Accept: application/octet-stream pour accéder en lecture à un usage particulier.
Structuration des métadonnées
A noter: la structuration va changer dans la prochaine release
La structuration d'un Object est la suivante :
{
"#id": "ObjectId",
"#tenant": "tenantId",
//Métadonnées de l'Object
"FileInfo": {
"Filename": "filename",
"LastModified": "date",
"GPS": {}
},
"#qualifiers": [{
"qualifier": "PhysicalMaster",
"#nbc": 1,
"versions": [
{
"#id": "abcdef",
"DataObjectGroupId": "abcdef",
"DataObjectVersion": "PhysicalMaster_1",
"PhysicalDimensions": {},
"PhysicalId": {},
"xxx": "" // autres informations
}
]},
{
"qualifier": "BinaryMaster", // Version numérique
"#nbc": 1, // nombre de versions
"versions": [
{
"#id": "abcdef",
"#storage" : {// informations sur le stockage de l'objet}
"DataObjectGroupId": "abcdef",
"DataObjectVersion": "BinaryMaster_1",
"MessageDigest": "algorithme digest", // empreinte et algorithme d'empreinte de l'objet
"Algorithm": "SHA-512",
"FileInfo": {// informations du fichier},
"Size": 10, // taille de l'objet
"Uri": "Content/uri", // uri de l'objet
"FormatIdentification": {
"FormatLitteral": "format Literral",
"MimeType": "mimetype",
"FormatId": "pronomId"
},
"OtherMetadata": {
// autres métadonnées non classées
}
}
]
},
{
"qualifier": "Dissemination", // Version de diffusion
"#nbc": 1, // nombre de versions
"versions": [
{//idem à BinaryMaster}
]
},
{
"qualifier": "TextContent", // Contenu brut
"#nbc": 1, // nombre de versions
"versions": [
{//idem à BinaryMaster}
]
},
{
"qualifier": "Thumbnail", // Vignette
"#nbc": 1, // nombre de versions
"versions": [
{//idem à BinaryMaster}
]
}
],
"#unitups": [ "unitParentId", "unitParentId"],
"#nbobjects": 1, // Nombre de versions d'objets contenus pour tous les usages
"#storage": { "#nbc": 2 }, // information de stockage,
"#originating_agency": "originationAgencyId",
"#originating_agencies": [ "originationAgencyId" ],
"#operations" : [ "operationId" ] // liste des opérations auxquelles ce groupe d'objets a participées
}
Note : A l'avenir, à l'intérieur d'une version d'usage, et pour chaque version (pour les BinaryMaster notamment), un contexte sera ajouté à la structure de l'Object afin de pouvoir y introduire des données de contexte (version du référentiel Pronom par exemple...).
Dipexport api
/dipexport (en v1 ou en v2) sont les points d'entrée permettant l'export sous forme de DIP (paquet d'information diffusé ou Dissemination Information Package en anglais) d'une sélection d'unités archivistiques.
Important : Deux actions sont disponibles. La première permet de lancer un processus de génération d'un DIP. La deuxième permet de télécharger le fichier généré par le processus précédent, une fois terminé.
Champs d'application sur les Units
Les principes sont les suivants :
- Le POST peut être utilisé pour des opérations de mises à jour en masse. Il peut aussi être utilisé avec le header X-Http-Method-Override: GET pour réaliser un GET avec un BODY.
- Le PUT est utilisé pour réaliser un update partiel (déprécié), à partie de la release 16, le POST (massUpdate) doit être utilisé pour effectuer une mise à jour d'unités archivistiques.
- Pas de DELETE car ceci relève de l'élimination
- GET correspond à la recherche ou l'accès selon la présence d'un body ou non
- Un seul Object par Unit max
- Une requête depuis un Unit signifie recherche relative depuis celui-ci (roots = this)
- Accept: application/json signifie les métadonnées au format Json
- Accept: application/octet-stream signifie le retour du contenu binaire de l'Object
ArchiveUnits
API qui définit les requêtes pour accéder aux Unités d'archives. La requête utilise le langage de requête DSL de Vitam en entrée et retourne une liste d'Unités d'archives selon le DSL Vitam en cas de succès.
Requête qui retourne des résultats contenant des Unités d'archives. La requête utilise le langage de requête DSL de type recherche multiple (SELECT MULTIPLE) de Vitam en entrée et retourne une liste d'Unités d'archives selon le DSL Vitam en cas de succès.
Permissions requises:
- units:read
Requête qui déclanche la mise à jour de masse des métadonnées descriptives des unités archivistiques. Sans le Header, le point d'API est utilisé pour mettre à jour en masse les métadonnées descriptives des unités archivistiques. Possibilité de remplacer une chaîne de caractères par une autre vià l'opération $setregex.
Avec le Header, La requête utilise le langage de requête DSL de type recherche multiple (SELECT MULTIPLE) de Vitam en entrée et retourne une liste d'Unités d'archives selon le DSL Vitam en cas de succès. La requête utilise POST avec X-Http-Method-Override: GET Permissions requises:
- units:update
Requête qui déclenche la récupération de toutes les unités d'archives dans un Json Stream.
Permissions requises:
- units:stream
Requête qui déclenche la mise à jour de masse des métadonnées de gestion d'unités d'archives. La requête utilise un POJO spécifique pour effectuer la mise à jour des éléments de gestion.
Permissions requises:
- units:rules:update
Request Calcule/Supprime les règles héritées pour les unités archivistiques répondant aux critères de la requête DSL.
Request that will launch the computation
Permissions requises:
- computeInheritedRules:action
Request that will delete the computation
Permissions requises:
- computeInheritedRules:delete
API qui définit les requêtes pour accéder à une Unité d'archive. La requête utilise le langage de requête DSL de Vitam en entrée et retourne une liste d'Unités d'archives selon le DSL Vitam en cas de succès.
Requête qui retourne une Unité d'archive. La requête utilise le langage de requête DSL de type recherche unitaire (GET BY ID) de Vitam en entrée et retourne une liste d'Unités d'archives contenant 1 seul résultat selon le DSL Vitam en cas de succès.
Permissions requises :
- units:id:read:json
[DEPRECATED] - Be careful, this endpoint is no longer acceptable for updating units. Use POST /units instead.
Requête qui modifie une Unité d'archive.
La requête utilise le langage de requête DSL de type modification unitaire (UPDATE BY ID) de Vitam en entrée et retourne le statut de la mise à jour en résultat selon le DSL Vitam en cas de succès.
Permissions requises:
- units:id:update
API qui définit les requêtes pour accéder à l'Objet d'archives associé à l'Unité d'archives si elle existe. La requête utilise le langage de requête (DSL) de Vitam en entrée et retourne l'objet d'archives selon le DSL Vitam en cas de succès.
Requête qui retourne le résultat contenant un Object d'archives : ses métadonnées ou un de ses objets binaires. Dans le cas des métadonnées, la requête utilise le langage de requête DSL de type recherche unitaire (GET BY ID) de Vitam en entrée. 'Accept' header est 'application/octet-stream' (objet binaire) ou 'application/json' (métadonnées) Permissions requises:
- units:id:objects:read:json
ou
- units:id:objects:read:binary
Requête qui retourne le résultat contenant un Object d'archives : ses métadonnées ou un de ses objets binaires. Dans le cas des métadonnées, la requête utilise le langage de requête DSL de type recherche unitaire (GET BY ID) de Vitam en entrée. 'Accept' header est 'application/octet-stream' (objet binaire) ou 'application/json' (métadonnées) La requête utilise POST avec X-Http-Method-Override: GET.
Endpoint d'API pour la création de Demandes d'Accès depuis une offre froide à des Objets d'archives.
Création d'une demandes d'accès à un objet d'archives associé à une unité d'archives.
Si l'objet est persisté sur une offre de stockage « froide », une demandes d'accès est créée, et renvoyée.
Si l'objet est persisté sur une offre de stockage « chaude », aucune demandes d'accès n'est renvoyée.
La création d'une demandes d'accès, permet de pré-commander des données persistées sur une offre « froide », et de le mettre à disposition pour lecture.
L'appelant doit monitorer périodiquement le statut des demandes d'accès (typiquement toutes les quelques minutes ou heures).
Une fois une demandes d'accès est devient prête (READY), la disponibilité immédiate des données depuis l'offre « froide » est garantie.
La durée d'expiration d'une demandes d'accès, qui court à partir du moment où cette dernière devient prête, est paramétrée par l'administrateur de Vitam.
Au bout d'une durée configurée par l'administrateur, une demandes d'accès est purgée de l'offre (NOT_FOUND).
Une fois une demandes d'accès est expirée (EXPIRED) ou supprimée, la disponibilité des données n'est alors plus garantie.
IMPORTANT: Les demandes d'accès créées doivent être supprimées au plus vite, dès que la donnée a été récupérée. Un trop grand nombre et/ou volume de demandes d'accès non supprimées risque d'impacter les capacité de stockage du cache de l'offre « froide », ainsi que la stabilité de l'offre.
Permissions requises:
- units:id:objects:accessrequests:create
Requête qui déclanche la mise à jour unitaire des métadonnées descriptives de plusieurs unités archivistiques. La requête utilise le langage de requête DSL de type mise à jour unitaire de masse (BULK UPDATE) de Vitam en entrée. Permissions requises:
- units:bulk:update
ArchiveUnits with inherited rules
API qui définit les requêtes pour accéder aux Unités d'archives avec leurs règles de gestion héritées. La requête utilise le langage de requête DSL de Vitam en entrée et retourne une liste d'Unités d'archives avec leurs règles de gestion selon le DSL Vitam en cas de succès.
Requête qui retourne des résultats contenant des Unités d'archives ainsi que leurs règles de gestion héritées. La requête utilise le langage de requête DSL de type recherche multiple (SELECT MULTIPLE) de Vitam en entrée et retourne une liste d'Unités d'archives avec leurs règles de gestion selon le DSL Vitam en cas de succès.
Permissions requises:
- unitsWithInheritedRules:read
Groupe d'objet
API qui définit l'ensemble des requêtes sur les groupes d'objets.
Requête qui retourne des résultats contenant des Groupes d'objets. La requête utilise le langage de requête DSL de type recherche multiple (SELECT MULTIPLE) de Vitam et peut utiliser l'opérateur $subobject (Voir documentation DSL) en entrée et retourne une liste d'Unités d'archives selon le DSL Vitam en cas de succès.
Permissions requises:
- objects:read
Requête qui retourne des résultats contenant des Groupes d'objets en utilisant le verbe POST et le header X-Http-Method-Override: GET. La requête utilise le langage de requête DSL de type recherche multiple (SELECT MULTIPLE) de Vitam et peut utiliser l'opérateur $subobject (Voir documentation DSL) en entrée et retourne une liste d'Unités d'archives selon le DSL Vitam en cas de succès.
Restauration des métadonnées
API qui restaure les métadonnées essentielles
Requête qui permet la restauration des métadonnées essentielles des unités archivistiques.
Permissions requises:
- units:update:revert
DIP Export
API qui définit les requêtes pour générer un DIP (Dissemination Information Package : ZIP contenant les métadonnées et les objets) pour une sélection d'Unités d'archives. La requête utilise le langage de requête (DSL) de Vitam en entrée et va lancer un processus générant le DIP selon le DSL passé. Une autre requête pourra être exécutée par la suite pour télécharger le fichier Zip généré.
response : JSON asynchronous state / HTTP CODE 202 or 500 for Internal Server Error La requête utilise le langage de requête DSL de type recherche multiple (SELECT MULTIPLE) de Vitam en entrée.
Permissions requises:
- dipexport:create
Télécharger le DIP généré par l'opération passée en paramètre
Requête qui retourne les résultats composés des métadonnées et des objets binaires dans un fichier zip 'Accept' header est 'application/octet-stream'
Permissions requises:
- dipexport:id:dip:read
DIP Export V2
API qui définit les requêtes pour générer un DIP (Dissemination Information Package : ZIP contenant les métadonnées et les objets) pour une sélection d'Unités d'archives. La requête est composée d'une dslRequest (DSL) et d'autres paramètres nécessaires pour le service. Un processus générant le DIP V2 selon le DSL passé sera lancé. Une autre requête pourra être exécutée par la suite pour télécharger le fichier Zip généré.
response : JSON asynchronous state / HTTP CODE 202 or 500 for internal error La requête utilise le langage de requête DSL de type recherche multiple (SELECT MULTIPLE) de Vitam en entrée.
Transfert d'archives
API qui définit les requêtes pour générer un transfert d'une sélection d'unités d'archives. La requête est composée d'une dslRequest (DSL) et d'autres paramètres nécessaires pour le service. Un processus générant le SIP selon le DSL passé sera lancé. Une autre requête pourra être exécutée par la suite pour télécharger le fichier Zip généré.
response : JSON asynchronous state / HTTP CODE (202, 200) or (412, 500 else) La requête utilise le langage de requête DSL de type recherche multiple (SELECT MULTIPLE) de Vitam en entrée.
Permissions requises:
- transfers:create
Télécharger le SIP généré par l'opération passée en paramètre.
Requête qui retourne un SIP au format ZIP 'Accept' header est 'application/octet-stream'.
Permissions requises:
- transfers:id:sip:read
Elimination
API qui définit les requêtes pour l'élimination des unités archivistiques.
Opération d'analyse des unités archivistiques éliminables.
Exécute une opération d'analyse d'élimination des unités archivistiques.
Permissions requises :
- elimination:analysis
Opération d'élimination définitive des unités archivistiques éliminables.
Exécute une opération d'élimination définitive des unités archivistiques.
Permissions requises:
- elimination:action
Journaux d'accès
API qui permet de lancer des actions relatives aux journaux d'accès aux objets binaires des unités archivistiques.
Lancer la récupération des journaux sous la forme d'un ZIP contenant des fichiers de log au format Json Lines. La requête prend en paramètre un objet Json pouvant contenir une date de début (StartDate) ou de fin (EndDate) pour filtrer les journaux.
Permissions requises:
- storageaccesslog:read:binary
Préservation
Opération de préservation des unités archivistiques.
Exécute une opération de préservation sur (une ou) les unités archivistiques.
Permissions requises:
- preservation:update
Transfer Reply
Démarage du traitement de l'ATR adressé par le SAE cible dans le cas d'un transfert
Démarage du traitement de l'ATR adressé par le SAE cible dans le cas d'un transfert.
Permissions requises:
- transfers:reply
Mise à jour d'arborescence
API qui définit les requêtes liées à la mise à jour d'arborescence des unités archivistiques
Lancement d'une ou plusieurs modifications d'arborescence d'unité archivistiques
Endpoints
API qui liste les endpoints de la ressource /access-external/{version}.
Suppression des versions des groupes d'objets
Opération de suppression des versions des groupes d'objets.
Exécute une opération de suppression des versions des groupes d'objets.
Permissions requises:
- objects:deleteGotVersions
Gestion des demandes d'accès depuis offre froide.
APIs de gestion des demandes d'accès à des objets depuis une offre froide.
Vérification du statut d'un lot de demandes d'accès.
Pour chaque demande d'accès, un statut est renvoyé :
- READY : La demande d'accès est prête.
- NOT_READY : La demande d'accès est n'est pas encore prête.
- EXPIRED : La demande d'accès a expiré.
- NOT_FOUND : La demande d'accès n'est pas trouvée (supprimée, purgée au bout d'un délais après expiration, non existante ou non visible depuis le contexte du tenant d'appel...)
L'appelant doit monitorer périodiquement le statut des demandes d'accès (typiquement toutes les quelques minutes ou heures). Une fréquence d'appel trop rapide peut avoir un impact sur les performances de l'offres en particulier, et de Vitam en général.
Une demande d'accès est uniquement visible dans le contexte de son tenant, et sera donc perçue comme NOT_FOUND depuis tout autre tenant.
Permissions requises:
- accessrequests:check
Suppression d'une demande d'accès.
Une fois une demandes d'accès supprimée, la disponibilité des données n'est alors plus garantie.
La suppression d'une demande d'accès inexistante est sans effet (idempotence). De même, une demande d'accès est uniquement visible dans le contexte de son tenant.
IMPORTANT: Les demandes d'accès créées doivent être supprimées au plus vite, dès que la donnée a été récupérée. Un trop grand nombre et/ou volume de demandes d'accès non supprimées risque d'impacter les capacité de stockage du cache de l'offre « froide », et la stabilité de l'offre.
Permissions requises:
- accessrequests:remove