L'obiettivo di un servizio in SOA è di eseguire una logica che, altrimenti, dovrebbe essere duplicata tra gli altri servizi. Questa logica è, a sua volta, la ragione per cui il servizio esiste.
Nel tuo caso, non aggiungi alcun valore attraverso il servizio. Qualsiasi altro servizio potrebbe facilmente accedere a S3 direttamente, dato che S3 è stesso un servizio (non è il tuo servizio, ma è irrilevante qui).
Non solo non vi è alcun valore aggiunto per il servizio di intermediazione, ma il suo costo è piuttosto proibitivo. Puoi immaginare di poterne creare uno in poche ore, il che è vero. Tuttavia, per avere qualcosa che funziona in modo affidabile e gestisce tutti i casi limite, devi occuparti di cache, ridondanza, upload e ripristino interrotti, file di grandi dimensioni, timeout, forza bruta e DDOS, caratteri speciali nei parametri, permessi e IAM, e dozzine di altre cose carine.
Pertanto, stai per passare due o tre settimane di sviluppo e forse una settimana di debug (YMMV, non conosco la tua esperienza in HTTP, SOA e la tecnologia che desideri utilizzare per creare il tuo servizio, ma anche se hai molta esperienza, non dovresti aspettarti di spenderne meno di due settimane, che è molto ).
I just wanted to know how it's done in commercial/big projects.
Le aziende pagano in media $ 700 al giorno per uno sviluppatore con molta esperienza, quindi data la mia stima di due settimane, sei a $ 7000 per un'attività. I progetti commerciali riguardano il denaro; quando c'è la possibilità di salvare un importo anche di $ 7.000, lo faranno.
Oltre a questo costo diretto, c'è un costo in termini di hosting e manutenzione del codice. Questo servizio dovrà essere mantenuto per anni, aggiungendo al conto molto più del prezzo originale. Di nuovo, tutto questo denaro sprecato senza la chiara comprensione di cosa potrebbe un simile servizio salvare nella società. Non risparmia larghezza di banda, né altre risorse. Non riduce l'importo che si paga ad Amazon, quindi ...
Questo non è tutto. Aumenterà anche il costo della manutenzione di tutti i progetti che dipendono dal servizio di intermediazione. Se un servizio:
- Deve essere corretto e la patch richiede un cambio di interfaccia,
- Dev'essere spostato in un'altra posizione, con una modifica nel suo URL,
- È disattivato, richiedendo un interruttore automatico per garantire che il servizio client non scenda a sua volta,
- È deprecato, che richiede la migrazione del client a qualcos'altro,
è necessaria la manutenzione immediata e imprevedibile e di solito è anche costosa. Ora, è molto più probabile che queste quattro cose accadano al tuo servizio rispetto a Amazon S3. Non perché tu sei un cattivo sviluppatore, no. Ma perché la scala di Amazon è leggermente diversa dalla scala del tuo servizio, il che significa che hanno molto più lavoro da pagare per garantire che i client possano contare su S3.
Infine, molti sviluppatori hanno una precedente esperienza con Amazon AWS (e possibilmente S3). Ciò significa che quando assumi un nuovo ragazzo, può facilmente capire come un servizio stia memorizzando i file se utilizza direttamente S3. Se si aggiunge un livello di riferimento indiretto, questo vantaggio viene perso. E, cosa più importante, ogni volta che qualcuno ha un problema con lo storage, dovrebbe chiedersi se il problema proviene dal servizio clienti, dal proprio intermediario o da S3. Questo aggiunge al tempo di debug.
Is it a clean/good-design-patterns-compliant approach ?
No. Aggiungi servizi quando aggiungono valore. Non rendere le cose più complesse di quelle che devono essere (KISS) e, in particolare, non aggiungere livelli che non portano benefici.
What is good/bad about that approach?
Che cosa è buono: il fatto che tu fornisca un'interfaccia molto più semplice rispetto a S3. Per gli sviluppatori che non hanno familiarità con AWS, S3 può essere piuttosto complesso.
Cosa c'è di male: già detto sopra.
How could I do that in a better way ? (don't want to store files (content) on the machine where application is running [locally] )
Chiamando direttamente S3.