Archiviazione file condivisa per diversi progetti API Web

Question

Archiviazione file condivisa per diversi progetti API Web

#1 da (2 voti)
#2 da (1 voti)
#3 da (1 voti)

2

Sto progettando un'applicazione web che dovrebbe essere un "punto di ingresso" per alcuni strumenti di elaborazione dei file.

Consente di chiamare l'app principale il "Connettore" e gli strumenti saranno "Strumento1", "Strumento2" ecc.

Gli strumenti verranno installati su server separati ed espongono un'API REST (il mio design).

I file devono essere memorizzati da qualche parte in una posizione centrale condivisa, in modo che non vengano trasferiti tra i servizi.

L'idea è la seguente. L'utente carica un file nel "Connettore". Voglio prendere il file valutare e utilizzare un repository di file per memorizzarlo su una condivisione di rete. L'archiviazione deve ancora essere decisa, quindi ho bisogno di una classe FileProvider generica che fornisca l'accesso ai file, indipendentemente dal fatto che sia un blob azzurro, un server FTP o una cartella condivisa su una rete.

Avrò a disposizione un database con EF che conserverà le informazioni sui metadati sui file (chi lo ha caricato, quando, nome del file, file guid etc). Dovrò quindi inviare una richiesta POST a Tool1, per elaborare il file. Voglio solo inviare l'ID del file, non il percorso effettivo.

Si suppone che Tool1 prelevi il file dalla posizione condivisa per ID e lo elabori, quindi salvi la versione elaborata di questo file nella stessa posizione condivisa e invii una chiamata di successo a "Connettore".

Il connettore quindi valuterà il file e forse invierà una richiesta REST simile a "Tool2" - di nuovo, solo con l'ID del file. Stessa storia, in sostanza.

Il problema che sto avendo è ... Affinché i file vengano selezionati per ID, i progetti WebApi di "Strumenti" dovrebbero avere accesso allo stesso database. È un approccio corretto?

Volevo che le API di Tool fossero praticamente indipendenti e separate dall'app Connector e sembra che le stiano combinando ...

design rest

posta Bartosz 28.03.2017 - 17:25

fonte

3 risposte

Leggi altre domande sui tag design rest

Quando effettuare il porto vs quando sviluppare? Come unire due funzioni che fanno le stesse cose con variabili diverse

score 2 · Answer 1

Oltre alla risposta @eddyce.

Come hai detto, devi implementare una nuova astrazione tra il Connector e il File Storage System.

Quindi, perché non una seconda API REST ?.

Consente di chiamarlo StorageService . Il servizio potrebbe fornire il prossimo contratto:

POST / store (multipart / form-data)
GET / file / {fileId}

Ha tre dubbi:

salva i file nell'archivio file
salva i metadati del file nel DB.
cerca file

Nota: l'utilizzo di nosqlDB come mongoDB potresti fare tutti e tre con un solo sistema. Invece di due. Tuttavia, sono sicuro che dovrebbe essere già un prodotto nel cloud che lo fa.

È l'unico ad accedere al DB e all'archiviazione dei file. Di conseguenza, il protocollo tra Connector e Tools sarebbe simile al seguente:

L'utente carica un file sul Connector
Il connettore valuta il file
Il connettore invia il file al StorageService
Il StorageService memorizza il file e salva i metadati.
Il StorageService restituisce l'ID. Potrebbe anche essere un URI
Il connettore invia la risposta allo strumento.
Lo strumento recupera il file da StorageService ( o dall'URI ) e lo elabora

... e così via.

Può sembrare più complicato della codifica degli accessi diretti al DB e all'archiviazione dei file. Ma, fa molto meglio il design.

Perché? Perché:

La separazione delle preoccupazioni di ciascun componente.
Accoppiamento lento tra i componenti.
Più facile da ridimensionare.

Infine, StorageService potrebbe evolversi in molti modi.

Aggiunta di nuovi sistemi di archiviazione file
Fornire nuove azioni: copiare, spostare, rimuovere, checksum, comprimere, eseguire il backup, ecc.
Sicurezza: autorizzazioni, autorizzazione, autenticazione, ...
Fornire accesso pubblico ai file.
...

score 1 · Answer 2

Se vuoi solo inviare l'ID del file (ID dal database), allora tutto ciò che Tool1 e Tool2 possono utilizzare; richiederanno l'accesso al database per ottenere il resto delle informazioni sulla posizione del file, ecc. - perché non hanno altro da fare.

Per essere indipendenti, Tool1 e Tool2 avranno bisogno di una delle tre opzioni a cui posso pensare al momento:

Opzione 1: Ricevi il file vero da elaborare.

Opzione 2: Essere fornito con la conoscenza di dove si trova il file da elaborare.

Opzione 3: Avere un metodo per chiamare che restituisce il file da un determinato ID.

Oh, e anche: Essere fornito con la conoscenza di dove conservare il file elaborato.

L'opzione 1 richiederebbe il passaggio del file fisico a Tool1 e Tool2.

L'opzione 2 significherebbe passare la posizione del file a Tool1 e Tool2.

L'opzione 3 significherebbe fornire un modo per Tool1 e Tool2 per ottenere la posizione del file.

Opzione Oh, e significherebbe anche passare tale informazione quando usi le Opzioni 1 e 2, o essere in grado di ottenerla se usi l'Opzione 3.

Come ottenere le informazioni:

Potresti utilizzare un delegato in Tool1 e Tool2 che possono recuperare il file e successivamente un altro delegato per archiviare il risultato.

Il connettore può passare l'ID del file a Tool1 e Tool2, nonché un metodo (accessibile pubblicamente) che recupera un file da un determinato ID. Questo metodo potrebbe essere nell'app Connector (se riferito), oppure è possibile utilizzare IOC per individuarlo o come API REST separata che è possibile fornire / chiamare direttamente.

Infine, avrebbero usato l'altro delegato per ritrasferire il file elaborato al codice chiamante per archiviare dove lo desidera (condivisione di rete, database, ecc.)

Le app Tool1 e Tool2 potrebbero quindi utilizzare questi delegati e internamente non sapranno mai nulla riguardo al database (anche se esiste), da dove proviene il file o dove è archiviato il file elaborato.

score 1 · Answer 3

Il vincolo principale del tuo approccio è quando dici:

I want to only send the file ID, not the actual path.

questo complica la questione perché non hai intenzione di accedere ai metadati dei file da Tool1 senza che Tool1 effettui alcun tipo di richiesta, direttamente sul tuo db o su un metodo REST esposto da qualche parte nel Connector. Una soluzione leggermente più semplice potrebbe provenire dal tipo di archiviazione per il file che si utilizzerà: invece di utilizzare il file system, si potrebbe avere un altro db, un archivio di valori-chiave solo per i file e l'ID sarebbe la chiave per accedere al file e informazioni sui metadati da questo nuovo db.

In questo modo il connettore utilizzerà l'ID per archiviare il file e quindi invierà quell'ID a Tool1 o Tool2 che lo elaborerà e forse lo sposterà da qualche parte.

Idealmente avrei messo un altro livello REST davanti a questo nuovo db.