From 0194661467eb3258392f70564b0ef4c03220f0d6 Mon Sep 17 00:00:00 2001 From: Justin Coyne Date: Mon, 15 Apr 2024 12:26:37 -0500 Subject: [PATCH] Update 0020-purl-fetcher-api.md --- 0020-purl-fetcher-api.md | 79 +++++++++++++++++----------------------- 1 file changed, 33 insertions(+), 46 deletions(-) diff --git a/0020-purl-fetcher-api.md b/0020-purl-fetcher-api.md index b3ea400..dc3fc62 100644 --- a/0020-purl-fetcher-api.md +++ b/0020-purl-fetcher-api.md @@ -4,40 +4,39 @@ title: ADR-0020 nav_order: 23 permalink: records/0020 --- + # Create a publish/shelve API that support versions for access systems -* Status: drafted -* Decider(s): - * Access Team - * Infrastructure Team - * Andrew (Repository Admin) - * ... -* Date(s): - * Status (from above): 2024-03-14 - * ... +- Status: drafted +- Decider(s): + - Access Team + - Infrastructure Team + - Andrew (Repository Admin) + - ... +- Date(s): + - Status (from above): 2024-03-14 + - ... Technical Story: n/a ## Context and Problem Statement -Currently dor-services-app (DSA) and the SDR workflow system work together to orchestrate the three steps required for shelving and publishing an object to the access system. DSA needs to share knowedge with the access systems for how the files in both `/stacks` and `/purl` are to be structured. +Currently dor-services-app (DSA) and the SDR workflow system work together to orchestrate the three steps required for shelving and publishing an object to the access system. DSA needs to share knowedge with the access systems for how the files in both `/stacks` and `/purl` are to be structured. 1. Put content files on `/stacks` NFS mount () 1. Put metadata on `/purl` NFS mount () 1. Call the "purl-fetcher" API to transfer control of these objecs to the access system (mainly for indexing.) -Ideally, this would be a single API where the files are uploaded and metadata is posted (similar to the SDR deposit API). This would allow us to decouple DSA, from needing to mount the `/stacks` and `/purl` filesystems. +Ideally, this would be a single API where the files are uploaded and metadata is posted (similar to the SDR deposit API). This would allow us to decouple DSA, from needing to mount the `/stacks` and `/purl` filesystems. ## Decision Drivers -* We need to add support for versions of objects. An API allows the access team to fully control the implementation of the filesystem required for versions, without having to share that knowledge with DSA. +- We need to add support for versions of objects. An API allows the access team to fully control the implementation of the filesystem required for versions, without having to share that knowledge with DSA. ## Considered Options -* [option 1] -* [option 2] -* [option 3] -* ... +- Use a deposit API similar to sdr-api +- Continue to use 3-step deposit ## Decision Outcome @@ -45,44 +44,32 @@ Chosen option: "[option 1]", because [justification. e.g., only option, which me ### Positive Consequences -* [e.g., improvement of quality attribute satisfaction, follow-up decisions required, …] -* ... +- [e.g., improvement of quality attribute satisfaction, follow-up decisions required, …] +- ... ### Negative Consequences -* [e.g., compromising quality attribute, follow-up decisions required, …] -* ... +- [e.g., compromising quality attribute, follow-up decisions required, …] +- ... ## Pros and Cons of the Options -### [option 1] - -[example | description | pointer to more information | …] - -* Good, because [argument a] -* Good, because [argument b] -* Bad, because [argument c] -* ... - -### [option 2] - -[example | description | pointer to more information | …] - -* Good, because [argument a] -* Good, because [argument b] -* Bad, because [argument c] -* ... +### Use a deposit API similar to sdr-api -### [option 3] +This will allow us to leverage the activestorage API for transfering the files. We've already implemented this in SDR-API, so it won't be a big challenge to adopt it here. See -[example | description | pointer to more information | …] +- Good, because all files and metadata can be verified when we do the final post. +- Good, because all files and metadata go through a single API +- Good, because it abstracts away the implementation of /purl and /stacks filesystems. +- Bad, because we will need to account for orphaned files, that is files that are posted, but metadata is never sent. +- ... -* Good, because [argument a] -* Good, because [argument b] -* Bad, because [argument c] -* ... +### Continue to use 3-step deposit -## Links +Put files on /stacks mount, put metadata on /purl mount. Then call dor-fetcher. -* [Link type] [Link to ADR] -* ... +- Good, because proven setups +- Good, because it's simple +- Bad, because it will make it hard to change to versioned access system. We will have to rewrite it all anyway, and this will require both the sender and receving systems to coordinate that migration. +- Bad, because boundaries between systems should have APIs. +- Bad, because no validation of completeness happens.