BaurzhanSПонятно, что есть 2 способа

Есть 100500 способов со своими достоинствами и недостатками.

BaurzhanS- либо просто динамически генерировать список прямых ссылок, либо копировать в OutputStream.
"Прямая ссылка" это в итогде тоже самое копирование файла в сокет, только не вашим кодом, а средствами контейнера или web сервера.

BaurzhanSВторой способ не нравится, кажется каким-то неуклюжим
1) Какой недостаток кроме необходимости вручную копировать у второго способа? Считается ли такой подход "плохой практикой" или норм?

Куча всяких HTTP фич может быть реализована сервером. Докачки файла с определенной позиции, отправка по частям, управление кэшированием. Не зная что из этого существует и что из этого может понадобится, можно просто лишится этих фич.

BaurzhanSпервый способ не нравится тем, что спалю структуру файлов

Смело. Фильтры и forward, выходит, ещё не проходили?

BaurzhanS2) Как можно делать просто ссылки, при этом не палить структуру директорий на сервере? На ум приходит только выдавать ссылку вида домен/хеш, как в гуглодрайве, а потом, соответствие хешированного УРЛ-а нормальным файлам хранить в БД. Это нормальный подход? Ну или просто хешировать каждый УРЛ с какой-нибуль солью, типа пятая буква в урле и тогда-даже записей в БД не надо. Но нормален ли такой подход.
Можно и без БД генерить UID и хранить в глобальном контексте маппинг UID на путь. При остановке сервера UID-ы персистить через сериализацию HashMap. Переодически подчищать.
Да, можно и шифровать, но если нет уверенности, что оно вообще нужно, то зачем так усложнять? Что там такая секретная структура сервера, что злоумышленники будут сканировать? Достаточно любого простейшего алгоритма, по которому некий UID можно распаковать в полное имя файла. Можно просто для всех файлов UID нагенерить заранее.
Пользователи ссылками могут обмениваться?